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