- cross-posted to:
- news@lemmy.linuxuserspace.show
- cross-posted to:
- news@lemmy.linuxuserspace.show
You must log in or register to comment.
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).
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
run0will 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:-)
While it may be true that getting rid of SUID binary is ideal, widening systemd’s security surface area is much more concerning to me than the sudo binary.
This has already been possible, the patch modifying
run.cto be able to do this is not even 400 lines long and was mostly just exposing its feature in a different way. (the entire patch was <1.5k lines, with most being docs, tests and a bit of plumbing for the colored terminal)
So none of my environment variables come with? 😐
I would fucking hope not. TERM is explicitly passed along as the only exception, which is the only sensible default for temporary privilege elevation in a shell.
Sudo also blocks almost all environment variables, with the option to set or copy them on demand. I assume that
run0will 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.
But why should I visit the website (that by the way now returns 500) to know if I’m interested in the article?
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.
OpenBSD’s sudo replacement called “doas”. While it greatly simplifies the tool and removes much of the attack surface, it doesn’t change one key thing: it’s still a SUID binary.
Yall understand that what actually changed is a symlink? That
systemd-runis now linked fromrun0, and that’s enough to make a SUID-less sudo?Basically.
systemd-runwas already able to do it, all that really changed is the interface for it. The change torun.cin the patch itself was <400LOC, and the entire patch was <1.4k lines with most being docs, tests and utils for coloring the terminal.Didn’t know this, thanks for sharing!
Great. Another thing that makes non-systemd distros even more painful to use. /s I like systemd, but the people that called the OS Systemd/Linux were right, and that name becomes more accurate every day.
Does it give alternative to
sudo -e(sudoedit) too?i had the same question so I went through the source code and, for now, doesn’t seem like it has implemented such option.
As the other comment said, no. But I’ve had the idea and will to at some point write a
editscript (that I can just setEDITOR=to) that would just choose one of the first common editors. That could in theory have a-0option to run as root (there also probably looking throughrun0,doas,sudoandsu). Not the editor, but doing the editing on a temp file and then copying with rootOut of the box no. But it would be easy to implement if you don’t need very complex rules. (I don’t actually know how permissions work for sudoedit.)
sudoedit copies a file to a temp directory, invokes $EDITOR with that temp file, and after the editor process exits, it copies the file back to overwrite the original. This way you get your user preferred and configured editor, but it doesn’t have any elevated privileges.
Yes, but how do you configure who is allowed to edit which files in
/etc/sudoers?
