111–120 of 902 posts
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…
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?
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…
It's less "a new thing has been created with systemd" and more "a user interface was exposed for an existing functionality".
Earlier quoted context omitted.
The single beat reason for doing this is to get a coherent complete system. This is what every other person here says. You can not try to create a large coherent system and then tell people they shouldn't use that particular part. That is totally disingenuous. Systemd is DESIGNED to be an all or nothing deal.
> Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
Earlier quoted context omitted.
First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library. I'm not arguing against systemd, just that it seems to gro…
> First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. It absolutely is. sudo allows you to execute code as another user. If you want to do that without giving sudo itself administrative privileges, this has to be done through the service manager, which creates a completely new, elevated process and h…
> then come up with a better one.
Really?
But they already ship pkexec together with systemd anyway via polkit, why are they again reinventing a wheel they already reinvented? Unit files are a neat concept I don't want to miss again, but everything else done by Lennart seems to be an inceasingly stupid mistake born from hubris.
This seems like it won't break anything except really exotic scripts, I think it will probably be a good thing for at least the main target audience of systemd, id imagine it might somehow suck for others though.
If all you are using sudo on is a personal (i.e. single user) laptop/desktop to install packages, this (along with other things like pkexec or doas) would seem to present no issues (and personally, from what I can see, I'd be happy to run `run0` on my personal systems!), but sudo does significantly more than that, as is called out by the systemd devs in the linked post https://mastodon.social/@pid_eins/112353324518585654
sudo supports not just LDAP (for multi-user systems), but include various levels of logging (including logging stdin and stdout of commands), apparmor and selinux profiles, the BSD and linux audit subsystem and more in a simple, easy to read and edit config format (this is just me reading from the `sudoers(5)` man page).
Whereas it seems `run0` won't have a `sudoers` file, but will instead be configurable (implicitly) via polkit, which uses JS to write policies (which I'd view as a much harder and error-prone system than the current `sudoers` format). It's not clear to me how much of sudo is tied to SUID vs. having a separate daemon (i.e. how much would have to be ditched vs. how much could be mapped over).
I do feel this is systemd moving away from traditional multi-user unix systems to being a single-user system (targeting the laptop/desktop case, or where sys-admins are the only users of the system, and it's basically a container host).
Earlier quoted context omitted.
This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. >I don't think having an unit that generates units at runtime is an officially supported use case Are you sure? Can you tell me how I would find out?
> This doesn't answer the question. Also generators are started very early, before other units have been started, so if your system is already running and now you want to generate those units, depending on the state of the other units, they don't really help. That's the point. Any situation in which you have a system modify itself at runtime is a recipe for a headache. So you do your auto-generation first, then work…
You can't do auto generation if that generation depends on the output of some units. Generators can not solve that problem.
>Units are just supposed to start a command and little else.
What a bizarre thing to say. No, that is not just what units are for. I think you are severely misinformed about what systemd is. Units are supposed to take care of ordering accept IPC, define how to handle failures and manage devices.
That comment alone makes me believe that you just do not know what you are talking about at all. It completely misses why systemd is designed the way it is and what it tries to accomplish.
Earlier quoted context omitted.
>There is never any actual technical reasons it's always about vague things like not adhering to UNIX philosophy, lines of code or it being badly designed (without any real architectural criticism) I did not mention the first two, so please do not pretend I argued that. For bad design look at transactions. That is really dumb and makes the system near incomprehensible. The documentation is bad, dbus is literally so b…
> If you don't read my posts please do not respond to me. Look at the first post I made and carefully read it. I read your OP. It does not contain a technical / security criticism of run0. It's an angry, hand-wavey, vague rant against a project that took a design decision you apparently disagree with, but lacking any actual analytical evaluation of the thing up for discussion. This sort of top-level post shows up on…
Yes, I literally say there is nothing wrong with the idea, so you going ahead and demanding I criticize the idea, is just absurd.
Really, this is completely bizarre. I even say that the thinking behind replacing sudo is fine, yet you are here complaining that I don't deliver technical arguments against something which I even told you might be completely valid to do from a technical perspective. Baffling.
I was really hoping the next sudo replacement would borrow heavily on root as role[0] (if not being root as role). Feels like a missed opportunity to not use capabilities. [0]: https://www.sciencedirect.com/science/article/pii/S016740482...
Capabilities aren't guaranteed to be present, and in a lot of high-security situations aren't available (though obviously you could say that about sudo too)
Earlier quoted context omitted.
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?
First, getting rid of setuid (I guess you'd have to get rid of the whole thing, not just the permission bit) is not the same as making systemd an integral part of the OS. Second, when even the package maintainers can make such "trivial" mistakes, something is wrong. You'd expect a component such as systemd to be much more trustworthy than some random library. I'm not arguing against systemd, just that it seems to gro…
Also, even before the backdoor was discovered, the systemd team were making libxz be dynamically loaded only in the cases where it was needed which would have killed the backdoor dead. There's some evidence that this might have actually caused the backdoor to be sped up and hence led to its discovery. Claims that systemd has bad security have to explain why it was already implementing practices that would have blocked the xz backdoor without it even being discovered. That seems pretty decent to me.