Should Daemons Just Be Frontends to the OS Auditing System?
Linked by Dennis Heuer on Wed 25th Aug 2010 22:23 UTC
Linux I came across a news entry at Phoronix about a new init replacement, systemd, and curiously started a read into the surprisingly heavy matter. Systemd is by no means as simple as upstart. It does far more things far more straight and in more detail. The differences are so significant that they enforce quite different configuration strategies. One can argue for both, depending on the goal to reach. However, that's not what I want to write about. After having read what systemd is capable of, and how it does it, I began to put the existence of all system daemons - in their today's forms - in question.
E-mail Print r 2   · Read More · 16 Comment(s) http://osne.ws/ib9
Permalink for comment 438238
To read all comments associated with this story, please click here.
Systemd doesn't quite work like that
by Zifre on Thu 26th Aug 2010 00:27 UTC
Zifre
Member since:
2009-10-04

Many of the arguments in the article are based on an incorrect understanding of how SystemD works. Ultimately, an auditing system would not be capable of most of the things that SystemD does (unless it were made into a rampant layering violation ;) ).

Systemd observes the full system actively. It observes paths to be informed if a program attempts to access a socket. It observes hardware events to be informed if a resource is available. It even observes mountpoints to dynamically mount resources at access.

This is not completely true. SystemD doesn't have to actively observe and act upon any of the things that you mentioned. Sockets are created ahead of time, and SystemD leaves them alone (the kernel buffers the data). Hardware events are mainly observed by Udev (SystemD has very little hardware logic). And mount points are handled by AutoFS, also in the kernel.

More than that, it is principally capable of doing things a userspace supervisor can't, like stopping an action from happening or pausing it until something else is done. For example, if systemd recognizes a mountpoint access, it can mount the resource immediately. But, is that quick enough? Systemd has no influence on the accessing process and thus can't turn it into sleep until the mount happened.

Actually, SystemD can and does do this. It sets up AutoFS mounts. Any access will cause the process to block until the real file system is mounted. An auditing system would not be able to do this any better than SystemD can.

There are other obstacles systemd faces like described in this entry. It goes like inotify is worse because of no atomic access and thus creating racy conditions but found a weird workaround.

An auditing system would not be able to fix this problem. What is needed is a transactional file system. I am actually working on a transactional file system layer for the Linux kernel (about which I may write an article for OSNews someday ;) ).

Edited 2010-08-26 00:27 UTC

Reply Score: 5