4 ms·
The whole discussion of alternatives is, alas, akin to passing a hot potato around. I, for one, don't quite see how keeping a daemon whose only job is to execut
by WesolyKubeczek 5y ago
The whole discussion of alternatives is, alas, akin to passing a hot potato around. I, for one, don't quite see how keeping a daemon whose only job is to execute arbitrary privileged commands any safer. You can have a hole where it parses the request. You can have a hole where it checks whether the requesting party is indeed authorized to make such requests. You can have a hole at the point of it invoking execve(). Indeed, you can put in the same hole pkexec used to have! You still need to exercise due diligence to write that daemon as tightly as can be so all those places don't pose a risk.
But with having a resident daemon approach you lose the process ownership, which sometimes is damn handy to have. Accidentally granting root to do a wrong thing and then not even being able to kill the thing with Ctrl-C or xkill is quite disempowering.
- hedora 5y agoI still haven't gotten over the transition from init to systemd. One reason is that I'm unconvinced it makes sense to have a daemon that passes out root privileges after boot. I'm a fan of "keep it simple," and UNIX/Linux/BSD survived for decades without such a daemon.
- mst 5y agoI understand entirely on a philosphical level but while debugging systemd regularly makes me angry it's still less often than other people's SysV init scripts used to do so, so I've made my peace with why people were happy making the switch. Naturally I'd personally prefer rc.subr or s6 or nosh (though I've seen people footgun themselves with all of those too, albeit less often than SysV) but it is what it is, and most days I can bring myself to believe that the systemd transition was the sort of imperfect net win that's usually as good as you get in an ecosystem as complex as this one.