Run0, a systemd based alternative to sudo, announced

> Or in other words: the target command is invoked in an isolated exec context, freshly forked off PID 1, without inheriting any context from the client (well, admittedly, we do propagate $TERM, but that's an explicit exception, i.e. allowlist rather than denylist).

I think in practice, this is going to be an endless source of problems, so much so that it won't be adopted. The usual use case of sudo is that you have a normal shell command, making use of the environment for context in all the ways that shell commands do, but it doesn't have all the permissions it needs, so you add "sudo" as an adverb.

Sometimes it makes use of environment variables. Sometimes stdin or stdout is redirected to a file, or to something more exotic than a file. Sometimes that means it runs inside of a chroot, or a Docker container. Sometimes you care about which process group it runs in.

And sometimes the thing you're running is a complicated shell script or shell-script-like object, eg "sudo make install". In this case, you don't really know what its dependencies are. In fact this is a common enough case that, if run0 becomes widespread, I expect it'll have a flag or a set of flags that make it act exactly like sudo, and I expect people to wind up learning that they should always give run0 those flags.

And I'm kind of worried that when this breaks stuff, the systemd project is going to push forward with some plan to get rid of sudo, and not gracefully accept the feedback that this is breaking things. I'm particularly worried about this because of the whole saga of KillUsersProcesses breaking nohup and screen, which to my knowledge is still broken many years later.

I think what is perhaps something to consider is how much of an attack surface sudo is and how unaware people are of the fact. Many people think they can configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it. But they don't realize all the ways it can be abused for privilege escalation. Getting rid of all that configuration removes that false sense of security, which is a good thing, it has been a huge footgun in Linux for decades. Some incompatibility is price well worth paying for that imho

I think these problems are basically negligible because the amount of people trying to "configure sudo to be safe to use for unprivileged users, by only allowing specific things to run with it" is negligible. Virtually all users of sudo are using it on their own computer which they are the sole user and ultimately the administrator of. Even in corporate contexts where the company owns the machine instead of the user, I've only ever seen cases where the use of sudo is unrestricted albeit logged. Where are these organizations where developers or syaadmins are allowed to use sudo but only with white listed commands? I don't doubt that some people are doing this, I just think it's not common.

Replacing the whole of sudo with some weird new thing to better support a niche usecase seems disconnected from reality to me.

My last job was at a UK bank. All our *nix systems were configured with a specific whitelist of commands that could be run via sudo. We found this an enormous pain in the arse when the powers that be decided to deploy ansible everywhere, and found that none of its "become" methods would work if sudo was set up like that.