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.
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.
deleted by creator
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.
deleted by creator
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-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 commonsudo
risks. No distro has announced implementing this in place ofsudo
, and it wouldn’t make sense in the first place;sudo
does stuff like LDAP thatsystemd-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 withrun0
instead ofsudo
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 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 beforerun0
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 thansudo
, I don’t see why they shouldn’t be allowed to be happy about that. Personally, I’d rather seesudo
implement a daemon/client model rather thansystemd-run
having an alternativeargv[0]
, but untilsudo
gets better, this is the best we get.