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 438367
To read all comments associated with this story, please click here.
the_author
Member since:
2010-08-26

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 ;) )

i believe that SELinux is such a rampart layering violation. it even spreads into user-space libraries and tools. but the real fact SELinux proves is that auditing sytems are meant to become omnipotent. so, can you safely state that an auditing system will _not_ implement everything systemd is dreaming of into its observing code?
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.

this rather sounds like you agree to the simple truth that things are better done inside the kernel, and supervisors should only feed and serve. i conclude from this that systemd is quite working on the same layer/interface for just everything inside the kernel as the auditing system, and there _is_, as a result, doubled core functionality.
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.

again, my article targets at the cores of the implementations, the observing parts. if the auditing system can do this in the kernel, why we need it another time outside the kernel? in other words, if an auditing system can't do it _better_ than systemd, does that justify a layer in userspace? where should the generic observing interface reside, and how should userspace daemons settle on it? that is my question.
I am actually working on a transactional file system layer for the Linux kernel (about which I may write an article for OSNews someday ;) ).

this is interesting. could you please tell how it shall act (inside the kernel) and why an auditing system is not interested in it?

Reply Parent Score: 1