61–70 of 902 posts
sudo and su made sense when it was a multiuser time sharing system. You needed clear boundaries between each users of the system, and permission bits. If I’m running on my workstation or desktop just let me run the damn thing. I don’t need an unprivileged user. On TempleOS you can modify the running system in ways you can’t on Linux.
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…
In theory, yes. In practice, I had a lot of trouble ordering things correctly in non-trivial cases.
> it's quite annoying that the armchair linux experts complain about how "lol systemd is so stupid for reinventing the wheel, give me my shell scripts back"
I can only speak for myself, but I don't want the abysmal sysvinit scripts back. I just want a simple process supervision suite which is true to the UNIX way of doing things. The sysvinit/systemd dichotomy is false.
Runit and s6 are both very real alternatives to systemd. They lack a ton of features, but they are a way to reliably run services. They do use shell scripts, but not for the reasons sysvinit did. They are extremely simple and have a very small attack surface as a result. Runit itself is a spiritual descendant of daemontools which predate systemd by great many years.
The problem with systemd is that it's a mediocre solution to many problems. UNIX deserved better.
[Edit: whitespace]
Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replaceme…
You should look at it differently, and then it'll make perfect sense.
systemd has long stopped being just an init system. It's a system tooling suite. When thinking about systemd don't think "PID 1", think "Linux New System Software Suite". It's a big umbrella project in the style of Gnome and KDE.
For example, systemd-boot is a perfectly normal bootloader that's just been systemd-themed. It has a "ctl" tool, has the same command-line aesthetics as other systemd-group tooling, and so on. It's not in any way dependent or even interested in the init system.
Earlier quoted context omitted.
People blame systemd for making the liblzma problem larger than it should have been. https://marc.info/?l=openbsd-misc&m=171227941117852&w=2 "Liblzma ends up dynamically linked to sshd because of a systemd-related extension added by many Linux packagers that pulls in liblzma as an unrelated dependency." https://news.ycombinator.com/item?id=39866076 "openssh does not directly use liblzma. However debian and several ot…
So that's your best shot against systemd? - Linux packagers decide to patch sshd to use libsystemd for a notification, that could have been trivially done without this library. - libsystemd depends on libzlma - libzlma depends on xz And therefore, systemd is insecure? And what does this have to do with the fact that SUID is a terrible idea that needs to go?
> - libzlma depends on xz
> And therefore, systemd is insecure?
Yes. You have literally just described the way it is insecure. It bundles a large amount of functionality under a single system, and therefore anything using that functionality is at risk. You seem to be suggesting that Systemd would be secure if you didn't use it, which is obviously fallacious. Anything is secure if you don't use it. Systemd offers this functionality, and did it in an insecure way. You cannot blame users for that. Saying that people shouldn't be using a certain part of Systemd is really the same as saying that part shouldn't exist to begin with. The conclusion is obviously that Systemd should be smaller to decrease the chances of things like this happening.
Earlier quoted context omitted.
doas uses SUID
It either has to be SUID or it has be a daemon running as root (or with enough caps to make the difference not matter). Adding a needlessly verbose configuration ecosystem doesn't change that. I imagine there's going to be some cool stuff this can do with homed and userctl, but it's not like the fundamental problem of "this program can grant root privileges" can ever go away.
Linux processes inherit a lot of state from the parent which means it's absolute hell to make a secure setuid binary. And at any time the Linux kernel can add a new feature which will be inherited by a child process, but that the process can't defend against because it wasn't even a thing when the code was written.
Running a binary at all also goes through a complex set of initialization steps a lot of programmers barely know exist, let alone are able to understand fully.
systemd has been a net positive for the linux ecosystem. remember when you had to write bash scripts to start, stop, restart services and handle any other signals you want to send it? nowadays it's a unit file (basically just an ini file) away with relatively straightforward API. and you can actually declare startup dependencies and other useful relationships past just "prepend a number signifying when it should run…
Yeah, basically I've found that the people the more vocal against systemd are either not really knowing how it works behind the scenes, and just criticizing for the sake of it (or because other people do so), or criticizing from an ideological point of view (do one thing and do it well). They see systemd as an octopus, not following the unix ideology. Which I don't really agree tbh
Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replaceme…
I've spent a lot of time studying systemd alternatives. I believe the overall best design is Skarnet's s6, and that too includes a sudo-like program: https://skarnet.org/software/s6/s6-sudo.html I was very surprised when I learned about it, but it does make sense (for s6 at least). > There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. With s6, the idea is to replace a SUID bina…
Same idea with systemd-run.
Wasn't the recent liblzma attack already exploiting the fact that systemd has its hands in pretty much everything? Wouldn't this expand further the attack surface of systemd and the systems that connect with it?
I'm surprised he hasn't started writing his own kernel by now.
Why do they have to do this? This is really, really stupid. My issue isn't even that someone tries to replace sudo. That may or may not be a completely fine thing to do, depending on the state of sudo and what improvements can be made. But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replaceme…
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. There is absolutely no reason to tie your new sudo replacement to systemd. Absolutely none. The systemd developers are tying it to systemd because they are systemd developers. If somebody else made something like this, it wouldn't be tied to systemd. But somebody else hasn't made something lik…
What? Literally every single other group of software developers has managed to create two projects. Even Microsoft can do it.