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).
Sudo also blocks almost all environment variables, with the option to set or copy them on demand. I assume that run0 will have similar facilities to propagate variables on demand.
PS: This is my technical understanding. Personally, I don’t like systemd eating up all the other utilities.
I can’t wait for systemd to ship its own kernel next year.
Dude, just write down a couple of lines in your posts so that people can know what they’re about.
It’s a phoronix article, there’s never more than two paragraphs and a quote in there anyway.
You can read this blog post, authored as a series of tweets instead https://mastodon.social/@pid_eins/112353324518585654
I’m sticking with doas, thanks.
Yall understand that what actually changed is a symlink? That systemd-run is now linked from run0, and that’s enough to make a SUID-less sudo?
