Assumed Audience: Hackers.

Epistemic Status: Confident, but cautious.

If you missed the news, systemd now has a sudo replacement called run0.

And it blew up the Internet.

Now, replacing sudo has been on my radar. For one, I already switched to the simpler doas a year ago. Second, I came across this comment on LWN, which begins like this:

Another reason to be biased against SUID is that it’s a quick solution to the problem of users not having root access to the entire machine.

There are three different ways to run something as root on a Linux-like system (assuming that you’ve got an ordinary user account):

  1. Get someone to log in as root and run the command directly for you.
  2. Send a message over a suitable transport to something that runs the process for you - AF_UNIX sockets, SSH to localhost or similar, authenticating you and deciding whether you can do that.
  3. Get someone to make the command SUID and run it yourself.

And then it ends with this sad note:

Ideally, everyone would bother to do the second option for things that need to be privileged - but that’s a lot of work, and SUID is a “neat hack” that means you don’t need to do it.

I thought, “Cool idea,” and was about to move on when I saw the reply by NYKevin:

The thing is, between systemd and polkit, option 2 is far easier now than it has ever been in the past. I think we are pretty much at the point where suid could just be outright deprecated and it wouldn’t be that big of a deal. The anti-systemd crowd would not like that, of course, but what else is new?

I spat lava.

As a member of the “anti-systemd crowd,” I took offense! But not the way you think.

See, NYKevin is right. On all counts. First, systemd and polkit were, and are, close enough that suid could just be deprecated. Second, the anti-systemd crowd wouldn’t like it.

I’m offended that NYKevin would insinuate that deprecating suid wouldn’t be that big of a deal.

Because while it wouldn’t be a big deal generally, it would be a big deal for some individuals, including myself!

If suid were deprecated, people like me would have to scramble to find a solution, and fast! That’s a big deal!

Side Rant

“No, it’s not, Gavin; you’re just hating on systemd for no reason.”

Au contraire!

I have two computers that I use regularly. Both are running a distro of Linux.

My main machine runs a stripped down Gentoo install without systemd. My backup uses Ubuntu with systemd.

Last I looked, the just-logged-in state of my main machine has less than 40 processes running. And that includes niceties such as Compiz (picom) and RedShift.

My Ubuntu machine has over 300 processes in the just-logged-in state! Over 7 times as many!

Granted, some of the difference is due to running the default desktop environment of Ubuntu vs just Qtile. But that’s not much of the difference.

Three hundred processes means that systemd makes my machine less efficient than it could be.

On my main machine, I run fuzz testing, and the whole point of fuzz testing is to execute as many random inputs as fast as possible.

Three hundred processes, even if they are mostly idle, still take CPU time away from fuzzing.

Now, I don’t want to put words in NYKevin’s mouth, but one of the ways I interpreted that comment is that the systemd haters would hate that option 2, the best option.

And at least for me, that’s not true. I was interested in implementing it for education reasons.

And yes, to have a non-systemd solution.

Well, when run0 dropped, my own project moved from the leopard-guarded lavatory to first priority.

Why? Because now that run0 exists, the suid deprecation mentioned by NYKevin might not be far behind. And I needed a backup because doas would stop working too!

It has been just over a week, and though I don’t have much time per day, I have completed a working proof-of-concept.

It’s called urdo, and its source code is here.

Of course, not everything is working; urdo doesn’t send signals yet, for example. But the gist is there, and it does work, including running the command in the working directory of the client.

And as a special treat, I put in some minimal portability so that it could possibly run on Linux, FreeBSD, and OpenBSD. That is something that systemd’s run0 cannot do.

Regardless, you should not run urdo!

Yes, I’m serious.

urdo is not ready. In fact, I deliberately left in all of my debugging statements so that it would be unusable.

urdo is purely a proof-of-concept, and while it is good proof, it is designed for privilege escalation, so it is a security risk. It should be properly audited before people run it.

But it exists, so if suid deprecation appears on the horizon, I have a backup plan.