fanotify vs inotify: PID atomically im Event
Grundlagen: fanotify vs inotify
Beide Mechanismen, fanotify und inotify, dienen der Überwachung von Dateisystemereignissen. Während inotify auf Datei- und Verzeichnisänderungen reagiert, bietet fanotify erweiterte Funktionen wie Zugriffskontrolle und bessere Integration in Sicherheitskonzepte. Der entscheidende Unterschied für uns: fanotify liefert die PID des auslösenden Prozesses direkt im Event.
PID-Atomizität im Event
Bei inotify muss die Prozess-ID (PID) separat ermittelt werden, oft über zusätzliche Tools wie lsof oder auditd. Das führt zu Race Conditions und ist fehleranfällig. fanotify hingegen liefert die PID atomar im Event-Stream. Das ist entscheidend für unsere Monitoring-Pipeline auf sgit.space, wo wir Prozesszuordnungen ohne Verzögerung benötigen.
Performance-Overhead
fanotify hat einen höheren Overhead als inotify, besonders bei vielen gleichzeitigen Events. Auf unserer Self-Hosted-Plattform ist das jedoch akzeptabel, da wir priorisierte Pfade überwachen und nicht das gesamte Dateisystem. Die atomare PID-Lieferung rechtfertigt den Mehraufwand.
Sicherheitsrelevanz
Die direkte PID-Zuordnung erlaubt uns, verdächtige Prozesse sofort zu identifizieren und zu terminieren. Bei inotify wäre hierfür eine zusätzliche, unsichere Abfrage nötig. Auf sgit.space nutzen wir fanotify gezielt für kritische Pfade wie /etc oder /usr/local/bin.
Debugging-Vorteile
Die atomare PID im Event vereinfacht das Debugging erheblich. Wir können in unseren Logs direkt nachvollziehen, welcher Prozess welche Aktion ausgelöst hat. Bei inotify bleiben solche Analysen oft fragmentarisch.
Fazit: Wann welchen Mechanismus nutzen?
Für einfache Dateiüberwachung reicht inotify. Sobald jedoch Prozesskontext benötigt wird – etwa für Sicherheits- oder Audit-Zwecke – ist fanotify die bessere Wahl. Auf unserer Plattform setzen wir bewusst auf fanotify, wo es auf atomare PID-Zuordnung ankommt.
```