sudo isn’t simple at all. SUID binaries shouldn’t be LDAP clients, IMO. Unfortunate bugs like “user environment variables are used to select the editor” make all the complex configuration a huge risk, because permitting a single user to edit a single file suddenly gives the user full root access when they set the right env variables.
I have no specific love for run0 (doas works just as well) but sudo does way more than it should do in a binary with the SUID bit.
run0 doesn’t exist because systemd wanted to build their own sudo, they just realised their systemd-run already offers most sudo features so they may as well make them available to end users.
I mostly agree with your write-up here. That said, I do think that systemd does want to eliminate SUID. I also think they want to absorb most of the low level system plumbing.
I don’t think they want to change anything for non-systemd environments, but their solution not requiring SUID is just a nice little advantage.
Of course you can use the many systemd tools to replace a kludge of alternatives (just systemd vs dnsmasq+netplan+rsyslog+…) but most distros seem to selectively apply a few parts of systemd, and use their own preferred alternatives for the parts that systemd isn’t particularly great at.
There are other applications that use suid (like newuidmap). And there are programs that use capabilities (like ping). I’m pretty sure that this logic will be used to justify assimilating those applications too. But I’m sure that the crowd will cheer them on as if they did something revolutionary.
Nobody is “cheering” for anything here. Neither is anyone claiming they did something miraculous here. Windows’ elevation system has worked without something as risky as the SUID bit for decades, for instance. Using system services to spawn root (or NTAUTHORITY\SYSTEM) tasks has been a thing since what, Windows XP? systemd-run does a bunch of really cool stuff that I could consider revolutionary if the tools all line up, but this isn’t one of them.
All that’s happening is that one of the systemd devs is happy to announce a sudo alternative that doesn’t have the common sudo risks. No distro has announced implementing this in place of sudo, and it wouldn’t make sense in the first place; sudo does stuff like LDAP that systemd-run doesn’t even support, so it can’t be replaced. It’s taken years for Wayland to be enabled by default, I doubt we’ll see distros with run0 instead of sudo this decade. It’ll be available on recent distros and you can use it if you want, it’s up to you.
I’ve never seen doas come close to taking sudo’s place so I doubt this will change much. With Ubuntu and a few others having recently released a new LTS, it’ll be a while before run0 will be available in distros in the first place, if it doesn’t get patched out by the likes of Debian.
However, if people find run0 to be better than sudo, I don’t see why they shouldn’t be allowed to be happy about that. Personally, I’d rather see sudo implement a daemon/client model rather than systemd-run having an alternative argv[0], but until sudo gets better, this is the best we get.
sudoisn’t simple at all. SUID binaries shouldn’t be LDAP clients, IMO. Unfortunate bugs like “user environment variables are used to select the editor” make all the complex configuration a huge risk, because permitting a single user to edit a single file suddenly gives the user full root access when they set the right env variables.I have no specific love for
run0(doasworks just as well) butsudodoes way more than it should do in a binary with the SUID bit.run0doesn’t exist because systemd wanted to build their ownsudo, they just realised theirsystemd-runalready offers mostsudofeatures so they may as well make them available to end users.I mostly agree with your write-up here. That said, I do think that systemd does want to eliminate SUID. I also think they want to absorb most of the low level system plumbing.
I don’t think they want to change anything for non-systemd environments, but their solution not requiring SUID is just a nice little advantage.
Of course you can use the many
systemdtools to replace a kludge of alternatives (just systemd vs dnsmasq+netplan+rsyslog+…) but most distros seem to selectively apply a few parts of systemd, and use their own preferred alternatives for the parts that systemd isn’t particularly great at.There are other applications that use suid (like
newuidmap). And there are programs that use capabilities (likeping). I’m pretty sure that this logic will be used to justify assimilating those applications too. But I’m sure that the crowd will cheer them on as if they did something revolutionary.Nobody is “cheering” for anything here. Neither is anyone claiming they did something miraculous here. Windows’ elevation system has worked without something as risky as the SUID bit for decades, for instance. Using system services to spawn root (or NTAUTHORITY\SYSTEM) tasks has been a thing since what, Windows XP?
systemd-rundoes a bunch of really cool stuff that I could consider revolutionary if the tools all line up, but this isn’t one of them.All that’s happening is that one of the systemd devs is happy to announce a
sudoalternative that doesn’t have the commonsudorisks. No distro has announced implementing this in place ofsudo, and it wouldn’t make sense in the first place;sudodoes stuff like LDAP thatsystemd-rundoesn’t even support, so it can’t be replaced. It’s taken years for Wayland to be enabled by default, I doubt we’ll see distros withrun0instead ofsudothis decade. It’ll be available on recent distros and you can use it if you want, it’s up to you.I’ve never seen
doascome close to takingsudo’s place so I doubt this will change much. With Ubuntu and a few others having recently released a new LTS, it’ll be a while beforerun0will be available in distros in the first place, if it doesn’t get patched out by the likes of Debian.However, if people find
run0to be better thansudo, I don’t see why they shouldn’t be allowed to be happy about that. Personally, I’d rather seesudoimplement a daemon/client model rather thansystemd-runhaving an alternativeargv[0], but untilsudogets better, this is the best we get.