On Tue, Aug 5, 2014 at 3:16 PM, Frank Peters <frank.pet...@comcast.net> wrote: > Linux _used_ to adhere to these two principles, but currently it > is more and more moving toward monolithic development and much > reduced simplicity. I refer especially to the Freedesktop > project, which is slowly becoming the centralized headquarters > for everything graphical. I also mention systemd, with its plethora > of system daemons that obscure all system transparency.
Everybody loves to argue about which design is "simpler," the "unix way," etc. The fact is that while systemd does bundle a fairly end-to-end solution, many of its components are modular. I can run systemd without running networkd, or resolved, etc. The modular components have interfaces, though they aren't really intended to work with anything other than systemd. Honestly, I think the main differences are that it doesn't do things the traditional way. Nothing prevents you from talking to daemons via DBus, or inspecting their traffic. Also, a set of modular components engineered to work together is less likely to have integration-related bugs than a bunch of components designed to operate on their own. SystemD also allows some security-oriented optimizations, like private tmpdirs, making the filesystem read-only, reduced capabilities/etc. That isn't to say that you can't do this with traditional service scripts, but there are more barriers to doing it. Ultimately it is a lot more functional than a traditional init, so I do agree that the attack surface is larger. Still, most of the stuff that is incorporated into systemd is going to be running in some process on a typical server - much of it as root. The use of DBus also means that you can use policies to control who can do what more granularly. If you want a user to be able to shut down the system, I imagine that is just a DBus message to systemd and you could probably give an otherwise-nonprivileged user the ability to send that message without having to create suid helpers with their own private rules. The ability to further secure message-passing in this way is one of the reasons for kdbus, and Linus endorses that (but not some of the practices of its maintainers). I do suggest that you try using systemd in a VM just to see what it is about. If nothing else you might appreciate some of the things it attempts to solve just so that you can come up with better ways of solving them. :) Rich
