Re: Systemd, nightmare or opportunity?
Thomas Leonard <[email protected]>
| Newsgroups | gmane.comp.capabilities.general |
|---|---|
| Message-ID | <CAG4opy-A4OvQd3Teh8Pu=fAO3vS+zYco1AV7ZBq--8P_ojfO5A@mail.gmail.com> |
On 25 September 2014 08:33, Rob Meijer <rmeijer-qWit8jRvyhVmR6Xm/[email protected]> wrote: > As those of you who use Linux may know, more and more Linux distributions > are moving away from their init systems, and are moving to systemd. A > consortium of interdependent system programs that replace not only > init/startup, but a whole range of other functionality that were > previously handled by independent software in the unix line (do one thing, > do one thing good) that I feel loosely forms the philosophy that also > underlies capability discipline. On one side, it would seem that a move > away from this philosophy would be a move away from anything POLA related. > On the other side however, this also might provide an > opportunity/challenge for people concerned with least authority on the > language level. If we could come up with a drop-in least authority rewrite > of systemd in a capability secure language (David-Sarah might have a clue > about what language to pick ;-) ), this could definetely become the basis > for a much more robust version of Linux, that could easily be addapted by > all those distro's now moving towards this horrible systemd architecture. > > Any thoughts? What exactly is "horrible" about the architecture? Before, SysVinit/Upstart ran everything as root, relying on each program to open the sockets it desired and drop privileges. Now, systemd opens all sockets and passes them (capability-style) to the programs, which are run under a limited user account (there are also quite a few sandboxing features offered, such as private /tmp, private network namespaces, containers, etc). It also uses cgroups to group processes reliably (so killing a service really does kill all its processes), and (I think) provides reliable logging information (one service can't log messages appearing to be from another service). Being written in C is disappointing, but I can't imagine that anything else would have been politically acceptable. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA