4 ms·

It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe th

It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.

zeveb 10y ago
> It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.
- bandrami 10y ago
  PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
  - qwertyuiop924 10y ago
    Yep. Pretty much. The setup is that you have your init, which handles startup, shutdown, reaping, and runs your RC. From there, you'll run process montoring for daemons (this is sometimes integrated into rc, sometimes spun out, resulting in runit, s6, and the rest of the daemontools family). This is sometimes mashed together into one program. Sometimes RC and init are the same, and process monitoring is spun out. But that's the pattern. Most RCs and process managers also have the ability to run as PID 1 if you want them to, and many do. But it's not necessary, and it is a security liability (although not as much of one as systemd, which does so much more than all of this, and which people are trying to expose to the internet directly).
    - justinsaccount 10y ago
      > which people are trying to expose to the internet directly [citation needed].
      - qwertyuiop924 10y ago
        Bows Gladly, good sir. https://cfp.systemd.io/en/systemdconf_2016/public/events/21 https://cfp.systemd.io/en/systemdconf_2016/public/events/21 Sit back, and witness the insanity.
        justinsaccount 10y ago
        That's funny, because that's the same link referenced in the blog post, where david says: > That presentation is from the Cockpit project, which isn’t part of systemd and doesn’t even share its main developers. It’s as much “remote access to systemd” as using SSH and then invoking systemctl. and then further states in the 2nd blog post: > I certainly don’t buy his original argument (which he hasn’t repeated in his second post) that tools like Cockpit should change the view of systemd. Just like SSH or Remote Desktop in Windows, Cockpit is the tool providing the remote, privileged access; systemd is just on the server listening locally. Blaming systemd for a Cockpit-based compromise is like blaming the “dnf” utility for removing the web server packages after someone gets root over SSH. (Cockpit is neither developed by the systemd team nor installed by default in any distributions.) So.. > Sit back, and witness the insanity. Who is acting insane here? A systemd developer, or people spreading FUD?
        qwertyuiop924 10y ago
        First off, this doesn't defeat my point: people are trying to connect systemd to the browser. Secondly, no, I wasn't aware it was a separate project, because it didn't initially appear to be. Ordinarily, I'd assume it was, but frankly, at this point, I can totally see Lennart doing this. So yes, systemd isn't at fault, and I did miss it, and, to some degree, spread FUD, for which I am sorry. However, it's still a very silly idea.
- qwertyuiop924 10y ago
  All init should do, arguably, is start the RC, start up the system, shut down the system, and reap zombies. Shutdown should be handled by the RC, and then passed back through to init, which does the kill and actually properly shuts down the system. As such, it should be exposed via a pipe, or other mechanism to only that trusted program. That handoff would happen during boot. Reaping zombies and startup only receive input from the kernel, or indirectly from the user in the form of processes. If you want your init to integrate RC or process management (many do), sure, write it in a more complex language (but depend on external libraries minimally, and make sure it's statically linked!), but for the idea, minimal init, C is perfectly fine.

It's an acceptable language for writing the piece of software that init is supposed to be. However, systemd is for more complicated and integrated and unsafe than that piece of software.

zeveb 10y ago

> It's an acceptable language for writing the piece of software that init is supposed to be. Is it though? Although I can't think of a lot of vulnerabilities to be concerned of in PID 1, I can think of a few (perhaps something to do with reaping zombies?). Why even allow for that possibility? I see no reason why init(1) couldn't be written in Lisp, or Python (although the speed might not be great), or Go, or Rust, or Haskell, or ML.

bandrami 10y ago
PID 1 shouldn't have anything complicated about it. A comp sci student should be able to write it in 10 minutes. This is a solved problem[1]. A run control system, which should be a completely separate project, could easily be written in a higher-level language than C. For instance, the traditional Linux RC system is written in sh, and the official GNU RC system[2] is written in scheme. Daemon run control isn't a domain where performance is crucial; transparency is much more important there, so the argument for using a higher level language to control daemons is pretty strong. [1] http://git.suckless.org/sinit/ http://git.suckless.org/sinit/ [2] https://www.gnu.org/software/shepherd/ https://www.gnu.org/software/shepherd/
- qwertyuiop924 10y ago
  Yep. Pretty much. The setup is that you have your init, which handles startup, shutdown, reaping, and runs your RC. From there, you'll run process montoring for daemons (this is sometimes integrated into rc, sometimes spun out, resulting in runit, s6, and the rest of the daemontools family). This is sometimes mashed together into one program. Sometimes RC and init are the same, and process monitoring is spun out. But that's the pattern. Most RCs and process managers also have the ability to run as PID 1 if you want them to, and many do. But it's not necessary, and it is a security liability (although not as much of one as systemd, which does so much more than all of this, and which people are trying to expose to the internet directly).
  - justinsaccount 10y ago
    > which people are trying to expose to the internet directly [citation needed].
    - qwertyuiop924 10y ago
      Bows Gladly, good sir. https://cfp.systemd.io/en/systemdconf_2016/public/events/21 https://cfp.systemd.io/en/systemdconf_2016/public/events/21 Sit back, and witness the insanity.
      - justinsaccount 10y ago
        That's funny, because that's the same link referenced in the blog post, where david says: > That presentation is from the Cockpit project, which isn’t part of systemd and doesn’t even share its main developers. It’s as much “remote access to systemd” as using SSH and then invoking systemctl. and then further states in the 2nd blog post: > I certainly don’t buy his original argument (which he hasn’t repeated in his second post) that tools like Cockpit should change the view of systemd. Just like SSH or Remote Desktop in Windows, Cockpit is the tool providing the remote, privileged access; systemd is just on the server listening locally. Blaming systemd for a Cockpit-based compromise is like blaming the “dnf” utility for removing the web server packages after someone gets root over SSH. (Cockpit is neither developed by the systemd team nor installed by default in any distributions.) So.. > Sit back, and witness the insanity. Who is acting insane here? A systemd developer, or people spreading FUD?
        qwertyuiop924 10y ago
        First off, this doesn't defeat my point: people are trying to connect systemd to the browser. Secondly, no, I wasn't aware it was a separate project, because it didn't initially appear to be. Ordinarily, I'd assume it was, but frankly, at this point, I can totally see Lennart doing this. So yes, systemd isn't at fault, and I did miss it, and, to some degree, spread FUD, for which I am sorry. However, it's still a very silly idea.
qwertyuiop924 10y ago
All init should do, arguably, is start the RC, start up the system, shut down the system, and reap zombies. Shutdown should be handled by the RC, and then passed back through to init, which does the kill and actually properly shuts down the system. As such, it should be exposed via a pipe, or other mechanism to only that trusted program. That handoff would happen during boot. Reaping zombies and startup only receive input from the kernel, or indirectly from the user in the form of processes. If you want your init to integrate RC or process management (many do), sure, write it in a more complex language (but depend on external libraries minimally, and make sure it's statically linked!), but for the idea, minimal init, C is perfectly fine.