But with one key difference: it’s *not* in fact SUID. Instead it just asks the service manager to invoke a command or shell under the target user’s UID. It allocates a new PTY for that, and then shovels data back and forth from the originating TTY and this PTY. 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).
Unfortunately, this is about as easy as it gets. Practically though, it isn’t going to matter. It sounds like run0 will be a drop-in replacement for sudo. We will know for sure in about 3 days (at the rate at which they assimilate features).
I understood some of those words…
Unfortunately, this is about as easy as it gets. Practically though, it isn’t going to matter. It sounds like
run0
will be a drop-in replacement forsudo
. We will know for sure in about 3 days (at the rate at which they assimilate features).So there would be no practical benefits of switching?
It gets rid of one more SUID binary. That’s always a win for security.
Sudo probably is way more comfortable to use and has way more configurable, too – that usually does not help to make a tool secure either:-)