46 ms·

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 th

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 replacement to systemd. Absolutely none. This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason. I am very glad to have jumped ship from systemd. It is particularly bad software created by a team of people who engage in very bad practices and a totally unhealthy view of software in general.

dmm 3y ago
> they will force all their projects simultaneously onto all their users for absolutely no reason. That's just not true. Just because a system uses systemd the init system doesn't mean the it is forced to use the other components.
- constantcrying 3y ago
  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.
  - growse 3y ago
    > Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
    - constantcrying 3y ago
      Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
      - growse 3y ago
        And people are also telling you that tight integration is not a mandate. Having a bunch of stuff designed to work together does not mean that they're tightly coupled and can only work with their specific implementations. We've all got confirmation bias, the trick is to be aware of it.
        constantcrying 3y ago
        This is such a bizarre statement. Of course any system with tight integration demands more precise specifications. Literally systems engineer 101. This is such an absurd hill to die on.
        logicprog 3y ago
        You aren't making any sense. All of the components of system D are separate programs, and yes they are maintained by the same general project and designed to integrate well with each other, but just because components are designed to integrate well with other components from the same project if they are present, that doesn't remotely mean that all of the components are required. And I mean, the proof is in the pudding, there are plenty of distros that do not use all of the components of systemd. Also, doesn't Linux have a long history of creating integrated suites of programs designed to integrate well with each other and used together? Like GNU?
      - kergonath 3y ago
        A lot of people also point out that “integrated” ≠ “mandatory” and that it is not, in fact, an all or nothing deal.
- blueflow 3y ago
  The reverse is true: Trying to use a component like udev or logind or in the future, run0, will require the use of systemd. Either you use full systemd or you can't get any of the fancy stuff. Gentoo folks have eudev or seatd but thats an uphill battle.
  - timw4mail 3y ago
    You can't take OpenRC away from me!
deleted 3y ago
[deleted]
dcow 3y ago
Why is this stupid? It’s just an option for how to configure a system that uses systemd to allow commands to be run in a privileged execution context without a suid binary. What’s wrong with having options? Why don’t you propose a better solution? How would your non-systemd solution actually work?
Starlevel004 3y ago
> 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 like this. Sudo isn't going to just go away (unfortunately). You can keep using your CVE-ridden setuid binary as much as you want.
- constantcrying 3y ago
  >The systemd developers are tying it to systemd because they are systemd developers. What? Literally every single other group of software developers has managed to create two projects. Even Microsoft can do it.
  - SAI_Peregrinus 3y ago
    GNU didn't. Why should Systemd?
    - gkbrk 3y ago
      You can use almost any GNU project without depending on all the other GNU projects.
      - SAI_Peregrinus 3y ago
        This is different from Systemd how? You can't use any GNU project without depending on GNU libc (except glibc itself, trivially).
        enriquto 3y ago
        That is not true. I use gnu tools compiled with musl libc.
        gkbrk 3y ago
Faaak 3y ago
I find this quite clever. Yeah yeah, "systemd is bad, it's a monopoly, yadda yadda". Well, there's also a reason they are doing it, and many aspects of it (seatd, timesyncd, resolved, run), and more neat than cobbling together bash scripts. I like it
deng 3y ago
> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. It is not unexplainable at all. In fact, the article explains it very well. sudo allows you to execute code as another user. If you think about it, you could also replace sudo with ssh to localhost - just set a root password and allow root logins. Now, security-wise, this would obviously be a bad idea. Our current solution is to give the sudo binary itself administrative privileges, which is a slightly less bad idea, but still pretty bad. Systemd already handles logins, so it is quite obvious that it could also handle this problem very well, and in fact, it already does: there is a tool systemd-run which you can already use. It will create a completely new process and will handle communication to it, just like ssh, but without the above downsides.
- constantcrying 3y ago
  >Systemd already handles logins Exactly that was my objection.
  - deng 3y ago
    And I disagree with that. The 'sudo problem' is a good example why it makes sense to handle init and login by the same system (note I'm not meaning "same binary" here, in fact, they are separate binaries in systemd). The SUID approach for sudo has been a problem for decades, and it needs to go. I don't really care if it's done by systemd, or if we agree on another system like S6 that was mentioned in another thread - in the end, they work very similarly be replacing the old sudo with an IPC approach.
    - cryptonector 3y ago
      I agree with u/constantcrying. This should not be part of systemd. It should be a separate service [started by systemd]. Reasons: - systemd is a large beast -- no need to make it larger with unrelated things - the Unix philosophy seems to be applicable here - the result should be portable to non-systemd systems
lugu 3y ago
The article explains how this sudo replacement ties to systemd: > 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. I understand your frustration, but systemd isn't the first attempt to build an integrated system. It just happens to run on Linux. It isn't insane to develop software this way, from that perspective.
hxelk1 3y ago
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 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 binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root. > I am very glad to have jumped ship from systemd. All that aside, so am I.
- deng 3y ago
  > With s6, the idea is to replace a SUID binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root. Same idea with systemd-run.
Jonnax 3y ago
Is that really how they develop software? Because I'm pretty sure that most of the components are optional. You did not even discuss the reasoning given for not using sudo to instead hop on your soapbox to say it's bad software with bad practices and that they are stupid. It's annoying how in the the more surface level Linux communities there's 0 value in discussing systemd. "1 million lines of code for PID0!" The new thing is blaming systemd for that recent exploit even though distros were patching in the bug themselves. People analysing the exploit determined that a new version of systemd was going to prevent the exploit vector so the exploit seemed to have been rushed out. Isn't this just textbook FUD? What I've noticed is over the years is systemd would have identified a gap in functionality. Like systemd-homed having a solution for automatically encrypting home directory when the machine is suspended. Is that a functionality that OSX has had for years? Yes. But anti-systemd people will dislike it automatically.
- constantcrying 3y ago
  Why are you bringing up random arguments I didn't even make? No, I am a dedicated systemd hater ever since I spend over a month full time writing and debugging systemd services for work. Systemd (the init system) is just all around badly designed and executed, I have very little confidence in the developers and their technical abilities and their tendencies to expand into completely unrelated areas for seemingly no reason makes me quite concerned. I wouldn't blame the xz exploit on them, it is very hard to call it their fault in any way. But I do think it is a symptom of a system which has grown far too thin and wide.
  - Jonnax 3y ago
    Because your post is the repeating cliches that are under every discussion about systemd. You're essentially saying that the month you spent is enough for you to call it bad and the creators incompetent. What qualifies you to make a determination like that? 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) This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective? It's been about 10 years since systemd was adopted by Debian/Ubuntu/Redhat/Fedora etc. Millions of deployments over the years. The companies that build and are paid to support for years with SLAs the operating systems are using it without issue.
dale_glass 3y ago
> 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. 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.
- constantcrying 3y ago
  >systemd has long stopped being just an init system. I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.
  - dale_glass 3y ago
    What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.
    - constantcrying 3y ago
      How much time have you spent writing and debugging systemd init files?
      - dale_glass 3y ago
        I've written a fair amount. Nothing much to debug in most of them.
        constantcrying 3y ago
zokier 3y ago
Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising > But what makes me really upset is this completely unexplainable need to make everything part of one particular init system systemd is not init system, its and umbrella project for various core system components, which includes an init system. > There is absolutely no reason to tie your new sudo replacement to systemd well, in this case there is good reason to have it interact with service manager in general > 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 [...] 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 strictly speaking it's not 100% coupled to systemd specifically, it most likely uses systemds d-bus API, which is part of their "portable and stable" APIs and as such could be implemented by other service managers https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/ > This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers. The minimal systemd build has only init, journald, and udev, which is not exactly sprawling huge. All the rest of the projects are fully optional, and I believe quite many of them can actually work without systemd-init
- constantcrying 3y ago
  Half the people here tell me that systemd is great because it tries to create an integrated complete system, the other half tells me I can just pick and choose. Obviously one of these groups is lying.
  - thiht 3y ago
    Both can be true though, it can create an integrated system where everything systemd-* works together, but where you can replace any systemd-* you don’t like with something else
viraptor 3y ago
It's not unexplainable. Any init by design is supposed to spawn new processes with the given environment, permissions, capabilities. When you run "your-init-cli start foo", you're starting a new service process. run0 is just one step away from that, because it connects the terminal to that process. It's less "a new thing has been created with systemd" and more "a user interface was exposed for an existing functionality".
Dalewyn 3y ago
>This is a completely insane way to develop software, instead of creating a new piece of software in a separate project I appreciate and respect the KISS sentiment of doing one thing and doing it well, but oftentimes I also think open source programs' lack of integration with each other at a fundamental level is also one of its biggest downsides. Being a Windows wizard unlike most folks around these parts, seeing and using the tight integrations between all the Windows subsystems is frankly marvelous and I wish Linux could have something like that.
- tuna74 3y ago
  Linux is "just" an OS kernel. Integrations between user space programs have to be done by other people (like the systemd developers).
paulddraper 3y ago
> There is absolutely no reason to tie your new sudo replacement to systemd It is said right there: the reason is to avoid the awkward SUID issues, and to have a privileged process create the process.
- immibis 3y ago
  Instead you get awkward state management issues. Will the child really inherit everything it needs from the parent or has systemd forgotten to transmit something? If I chroot and then run0 will that process also run in the chroot? What about systems with older versions of systemd?
  - _flux 3y ago
    I imagine these questions are what might make this project non-trivial, but surely achievable. > If I chroot and then run0 will that process also run in the chroot? That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be that the policy can decide what to do in that case. But wouldn't you agree that it is better security hygiene to explicitly opt-in to inheriting properties when going to an elevated security level, instead of opting out from them?
    - immibis 2y ago
      I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.
      - _flux 2y ago
        If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment. But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place. I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try. In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward. In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.
deleted 3y ago
[deleted]

dmm 3y ago

> they will force all their projects simultaneously onto all their users for absolutely no reason. That's just not true. Just because a system uses systemd the init system doesn't mean the it is forced to use the other components.

constantcrying 3y ago
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.
- growse 3y ago
  > Systemd is DESIGNED to be an all or nothing deal. ^[Citation needed]
  - constantcrying 3y ago
    Again and again people in this thread have told me that the great thing about systems is that it delivers integrated tools.
    - growse 3y ago
      And people are also telling you that tight integration is not a mandate. Having a bunch of stuff designed to work together does not mean that they're tightly coupled and can only work with their specific implementations. We've all got confirmation bias, the trick is to be aware of it.
      - constantcrying 3y ago
        This is such a bizarre statement. Of course any system with tight integration demands more precise specifications. Literally systems engineer 101. This is such an absurd hill to die on.
        logicprog 3y ago
        You aren't making any sense. All of the components of system D are separate programs, and yes they are maintained by the same general project and designed to integrate well with each other, but just because components are designed to integrate well with other components from the same project if they are present, that doesn't remotely mean that all of the components are required. And I mean, the proof is in the pudding, there are plenty of distros that do not use all of the components of systemd. Also, doesn't Linux have a long history of creating integrated suites of programs designed to integrate well with each other and used together? Like GNU?
    - kergonath 3y ago
      A lot of people also point out that “integrated” ≠ “mandatory” and that it is not, in fact, an all or nothing deal.
blueflow 3y ago
The reverse is true: Trying to use a component like udev or logind or in the future, run0, will require the use of systemd. Either you use full systemd or you can't get any of the fancy stuff. Gentoo folks have eudev or seatd but thats an uphill battle.
- timw4mail 3y ago
  You can't take OpenRC away from me!

deleted 3y ago

[deleted]

dcow 3y ago

Why is this stupid? It’s just an option for how to configure a system that uses systemd to allow commands to be run in a privileged execution context without a suid binary. What’s wrong with having options? Why don’t you propose a better solution? How would your non-systemd solution actually work?

Starlevel004 3y ago

> 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 like this. Sudo isn't going to just go away (unfortunately). You can keep using your CVE-ridden setuid binary as much as you want.

constantcrying 3y ago
>The systemd developers are tying it to systemd because they are systemd developers. What? Literally every single other group of software developers has managed to create two projects. Even Microsoft can do it.
- SAI_Peregrinus 3y ago
  GNU didn't. Why should Systemd?
  - gkbrk 3y ago
    You can use almost any GNU project without depending on all the other GNU projects.
    - SAI_Peregrinus 3y ago
      This is different from Systemd how? You can't use any GNU project without depending on GNU libc (except glibc itself, trivially).
      - enriquto 3y ago
        That is not true. I use gnu tools compiled with musl libc.
      - gkbrk 3y ago

Faaak 3y ago

I find this quite clever. Yeah yeah, "systemd is bad, it's a monopoly, yadda yadda". Well, there's also a reason they are doing it, and many aspects of it (seatd, timesyncd, resolved, run), and more neat than cobbling together bash scripts. I like it

deng 3y ago

> But what makes me really upset is this completely unexplainable need to make everything part of one particular init system. It is not unexplainable at all. In fact, the article explains it very well. sudo allows you to execute code as another user. If you think about it, you could also replace sudo with ssh to localhost - just set a root password and allow root logins. Now, security-wise, this would obviously be a bad idea. Our current solution is to give the sudo binary itself administrative privileges, which is a slightly less bad idea, but still pretty bad. Systemd already handles logins, so it is quite obvious that it could also handle this problem very well, and in fact, it already does: there is a tool systemd-run which you can already use. It will create a completely new process and will handle communication to it, just like ssh, but without the above downsides.

constantcrying 3y ago
>Systemd already handles logins Exactly that was my objection.
- deng 3y ago
  And I disagree with that. The 'sudo problem' is a good example why it makes sense to handle init and login by the same system (note I'm not meaning "same binary" here, in fact, they are separate binaries in systemd). The SUID approach for sudo has been a problem for decades, and it needs to go. I don't really care if it's done by systemd, or if we agree on another system like S6 that was mentioned in another thread - in the end, they work very similarly be replacing the old sudo with an IPC approach.
  - cryptonector 3y ago
    I agree with u/constantcrying. This should not be part of systemd. It should be a separate service [started by systemd]. Reasons: - systemd is a large beast -- no need to make it larger with unrelated things - the Unix philosophy seems to be applicable here - the result should be portable to non-systemd systems

lugu 3y ago

The article explains how this sudo replacement ties to systemd: > 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. I understand your frustration, but systemd isn't the first attempt to build an integrated system. It just happens to run on Linux. It isn't insane to develop software this way, from that perspective.

hxelk1 3y ago

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 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 binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root. > I am very glad to have jumped ship from systemd. All that aside, so am I.

deng 3y ago
> With s6, the idea is to replace a SUID binary with an IPC mechanism. That does make sense, since (parts of) the init system need to be running as root. Same idea with systemd-run.

Jonnax 3y ago

Is that really how they develop software? Because I'm pretty sure that most of the components are optional. You did not even discuss the reasoning given for not using sudo to instead hop on your soapbox to say it's bad software with bad practices and that they are stupid. It's annoying how in the the more surface level Linux communities there's 0 value in discussing systemd. "1 million lines of code for PID0!" The new thing is blaming systemd for that recent exploit even though distros were patching in the bug themselves. People analysing the exploit determined that a new version of systemd was going to prevent the exploit vector so the exploit seemed to have been rushed out. Isn't this just textbook FUD? What I've noticed is over the years is systemd would have identified a gap in functionality. Like systemd-homed having a solution for automatically encrypting home directory when the machine is suspended. Is that a functionality that OSX has had for years? Yes. But anti-systemd people will dislike it automatically.

constantcrying 3y ago
Why are you bringing up random arguments I didn't even make? No, I am a dedicated systemd hater ever since I spend over a month full time writing and debugging systemd services for work. Systemd (the init system) is just all around badly designed and executed, I have very little confidence in the developers and their technical abilities and their tendencies to expand into completely unrelated areas for seemingly no reason makes me quite concerned. I wouldn't blame the xz exploit on them, it is very hard to call it their fault in any way. But I do think it is a symptom of a system which has grown far too thin and wide.
- Jonnax 3y ago
  Because your post is the repeating cliches that are under every discussion about systemd. You're essentially saying that the month you spent is enough for you to call it bad and the creators incompetent. What qualifies you to make a determination like that? 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) This is an article about why they believe sudo isn't a good system. Where's your criticism of that from a technical / security perspective? It's been about 10 years since systemd was adopted by Debian/Ubuntu/Redhat/Fedora etc. Millions of deployments over the years. The companies that build and are paid to support for years with SLAs the operating systems are using it without issue.

dale_glass 3y ago

> 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. 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.

constantcrying 3y ago
>systemd has long stopped being just an init system. I think that this has always been the core criticism of anyone who objects to them. Besides systemd, the init system, just being very poorly thought out.
- dale_glass 3y ago
  What's poorly thought out about the init system? It's not perfect for sure, but on the whole I don't have any issues with it.
  - constantcrying 3y ago
    How much time have you spent writing and debugging systemd init files?
    - dale_glass 3y ago
      I've written a fair amount. Nothing much to debug in most of them.
      - constantcrying 3y ago

zokier 3y ago

Instead of just hating based on assumptions it would be useful to actually familiarize with the thing you are critizising > But what makes me really upset is this completely unexplainable need to make everything part of one particular init system systemd is not init system, its and umbrella project for various core system components, which includes an init system. > There is absolutely no reason to tie your new sudo replacement to systemd well, in this case there is good reason to have it interact with service manager in general > 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 [...] 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 strictly speaking it's not 100% coupled to systemd specifically, it most likely uses systemds d-bus API, which is part of their "portable and stable" APIs and as such could be implemented by other service managers https://systemd.io/PORTABILITY_AND_STABILITY/ https://systemd.io/PORTABILITY_AND_STABILITY/ > This is a completely insane way to develop software, instead of creating a new piece of software in a separate project they will force all their projects simultaneously onto all their users for absolutely no reason The couplings between systemd projects are not that tight, you can pick and choose which parts you want, they explicitly are not "forcing all their projects" to consumers. The minimal systemd build has only init, journald, and udev, which is not exactly sprawling huge. All the rest of the projects are fully optional, and I believe quite many of them can actually work without systemd-init

constantcrying 3y ago
Half the people here tell me that systemd is great because it tries to create an integrated complete system, the other half tells me I can just pick and choose. Obviously one of these groups is lying.
- thiht 3y ago
  Both can be true though, it can create an integrated system where everything systemd-* works together, but where you can replace any systemd-* you don’t like with something else

viraptor 3y ago

It's not unexplainable. Any init by design is supposed to spawn new processes with the given environment, permissions, capabilities. When you run "your-init-cli start foo", you're starting a new service process. run0 is just one step away from that, because it connects the terminal to that process. It's less "a new thing has been created with systemd" and more "a user interface was exposed for an existing functionality".

Dalewyn 3y ago

>This is a completely insane way to develop software, instead of creating a new piece of software in a separate project I appreciate and respect the KISS sentiment of doing one thing and doing it well, but oftentimes I also think open source programs' lack of integration with each other at a fundamental level is also one of its biggest downsides. Being a Windows wizard unlike most folks around these parts, seeing and using the tight integrations between all the Windows subsystems is frankly marvelous and I wish Linux could have something like that.

tuna74 3y ago
Linux is "just" an OS kernel. Integrations between user space programs have to be done by other people (like the systemd developers).

paulddraper 3y ago

> There is absolutely no reason to tie your new sudo replacement to systemd It is said right there: the reason is to avoid the awkward SUID issues, and to have a privileged process create the process.

immibis 3y ago
Instead you get awkward state management issues. Will the child really inherit everything it needs from the parent or has systemd forgotten to transmit something? If I chroot and then run0 will that process also run in the chroot? What about systems with older versions of systemd?
- _flux 3y ago
  I imagine these questions are what might make this project non-trivial, but surely achievable. > If I chroot and then run0 will that process also run in the chroot? That's an interesting question and it's not quite clear to me what should be the answer. For example, one legit answer might be that it would not work at all (in which case you would need to use some other tool that fits your needs), or another would be that the policy can decide what to do in that case. But wouldn't you agree that it is better security hygiene to explicitly opt-in to inheriting properties when going to an elevated security level, instead of opting out from them?
  - immibis 2y ago
    I expect that when I run "sudo rm /foo" it should try to affect the same file as "rm /foo". Especially when I just checked, without sudo, that /foo was the correct file.
    - _flux 2y ago
      If there is a non-error effect in running sudo rm /foo, then indeed it should have the same effect as rm /foo as root in the chroot environment. But using sudo, or even root, in a chroot environment isn't good security practice in the first place. For example, the environment's /etc/sudoers, /etc/shadow, /etc/passwd can all be different (but actual user ids are shared), while the environment could mknod the root filesystem device, mount parts of the host under /usr and /home and quite possibly elevate its access to the host filesystem, in which case sudo in a chroot environment would interact with the host in perhaps ways that are not directly constrainable in sudoers in the first place. I imagine it's possible to carefully construct the chroot environment and craft /etc/sudoers in a way to avoid this, but I wouldn't even try. In a better contained system implemented with namespaces (as in docker) sudo should work as expected. I imagine e.g. with docker you could have a service that responds to the system dbus messages, either as a separate daemon in the container or something even provided by docker itself. Or, maybe the requests from the container could be forwarded to the main systemd, with information about the context the request comes from, and let it choose how to move forward. In the end I don't think I agree that a sudo replacement exchanging messages directly with the systemd is the best way to go. There could be another daemon, run by systemd (or not), that handles these messages. I suppose in the case of dbus there is no "dbus firewall" to limit the access to dbus as one can limit access to Unix domain sockets with plain old permissions, though, so perhaps the security benefits would be minimal in the dbus architecture.

deleted 3y ago

[deleted]