Hacker News new | ask | show | jobs
by bandrami 3439 days ago
If only UNIX provided an existing utility to do that...
2 comments

So you want pid1 constantly calling out to userland binaries to do basic filesystem manipulation tasks?
Well, I want PID 1 to make exactly one userland binary call and then start reaping orphans. I want that PID 2, the RC system, to read some configuration file(s) and, yeah, fork and exec a bunch of userland binaries. It's kind of the whole point, right?
What's the advantage of such an architecture?
The advantage is that the kernel panics if PID 1 ever crashes, so I want PID 1 never to crash or even be able to crash. It also means I want the binary to have as little of an attack surface as possible, and particularly I don't want it listening to dbus or having links to a QR generation library.

This is a solved problem with multiple good solutions [1] [2] [3], so I can easily avoid those issues by not using systemd.

[1] http://www.gnu.org.ua/software/pies/

[2] http://universe2.us/epoch.html

[3] http://core.suckless.org/sinit

So add a signal handler that just enters an endless loop. That's what systemd does, so as not to panic the kernel on a crash.

By the way, systemd doesn't listen to dbus (it uses the dbus protocol for IPC) and does not link to a QR generation library (journalctl does, which is your usual unprivileged program).

Great, now you have the issue of converting parameters to strings when invoking the binary. For example, the touched file's mode.