- cross-posted to:
- news@lemmy.linuxuserspace.show
- cross-posted to:
- news@lemmy.linuxuserspace.show
You must log in or register to comment.
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.
Accurate, but not bad, yes. It turns out standardized base systems and ABIs are important to an ecosystem.
Linux tried the disorganized free-for-all for two decades, and what we got was fragmented “Ubuntu admins”, “debian admins”, “redhat admins”, “suse admins”, and a whole shitload of duplicated effort in the packaging ecosystem, only for half the packages out there to be locked to Ubuntu or RHEL. So the corporate interests, and a fair number of the community efforts, centralized their problems and solutions into a small standardized suite in Mesa+Wayland+systemd+Pipewire+flatpak, etc
The result is a ton more interoperability, a truly open ecosystem where switching your distro doesn’t mean hiring different people and using different software, and a lot more stability and maturity.
And hey, if a user or distro wants to do their own thing, they can make and own their niche, same as before. Nothing lost.
It’s been kind of wild to watch over the past 15 years or so, makes me very hopeful for the next 15.
I agree that standardisation is good, but sudo is already a standard. If anything, I think this might, once again, split things further by creating another competing standard. It’s like that XKCD. But to be honest, I’m not an admin or enterprise customer yet, so I don’t know if this might not be an improvement. On an individual level, I’d be okay with run0 becoming a standard if it’s good enough, as long as we get a sudoedit or “sudo -e” replacement too, as I only discovered it about 2 months ago, but I already use it a lot.
deleted by creator
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?
