Wie möglichst früh eine Veränderung am Dateisystem erkennen?

[MrScoville]

Hallo,

ich habe folgendes kleines Problemchen... Ich möchte möglichst früh während der Boot-Phase erkennen können, ob eine bestimmte Datei verändert wird während des Bootens oder nicht -- und vor allem feststellen dann, welcher Prozess es denn gewesen sein könnte. Insbesondere ist wichtig dabei, dass ich die Mount-Phase des Dateisystems im konkreten Fall nicht einschätzen kann (nicht mein Server).

Jemand eine Idee, wie das umsetzbar ist? Im äußersten Notfall müsste ich wohl etwas coden, das sich nur auf Kernel-Routinen verlässt, aber vielleicht gibt's ja was von ratioph... Debian?

Danke und guten Rutsch!
Carsten

[sbruder]

inotify [1] hast Du schon probiert?
Wann im Bootprozess ist das denn? Der besteht aus vielen Phasen.

http://www.ibm.com/developerworks/linux ... index.html

[MrScoville]

Wann im Bootprozess ist das denn?

Ich mache es mal konkret. Irgendetwas (genauer kann ich es halt noch nicht sagen) überschreibt beim Booten /etc/resolv.conf. Ich habe schon den ganzen Server mittels grep scannen lassen und keine Lösung gefunden. Das heißt, die Sache ist wohl aus komischen Gründen tief im System versteckt.

Ich gehe mal davon aus, dass /etc zum / mount gehört, aber wann /lib und /usr gemountet werden? "GIYF" hat mir nicht weiter helfen können, also anders gesagt, mir ist nicht klar, wie der mount Prozess genau abläuft.

Was ich möchte, ist, dass bevor der systemd, der ja so "herrlich" parallel arbeitet, das Netzwerk hochfährt, ich die /etc/resolv.conf überschreiben kann. Aber wann diese Datei überschrieben wird, ja vielleicht auch danach oder eben mit einem Prozess, der genau inotify benutzt, weiß ich halt noch nicht.

[heisenberg]

resolv.conf wird AFAIK vom Paket "resolvconf" überschrieben. Würde mich jetzt nicht wundern, wenn systemd seine eigene Weise hat die Datei zu überschreiben. Da systemd-networkd aber noch nicht standard ist und Du dazu nichts gesagt hast, gehe ich mal vom Normalfall aus, dass Dein Netzwerk über /etc/network/interfaces konfiguriert wurde.

Der Zweck dahinter ist es die Einstellungen aus der Netzwerkkonfigurationsdatei /etc/network/interfaces in resolv.conf zu übernehmen.

Der 1. Ansatz wäre es also, die /etc/network/interfaces mit den richtigen Resolver-Einstellungen zu versehen. Siehe man-Page zu resolvconf(8).

[breakthewall]

Hallo,

ich habe folgendes kleines Problemchen... Ich möchte möglichst früh während der Boot-Phase erkennen können, ob eine bestimmte Datei verändert wird während des Bootens oder nicht -- und vor allem feststellen dann, welcher Prozess es denn gewesen sein könnte. Insbesondere ist wichtig dabei, dass ich die Mount-Phase des Dateisystems im konkreten Fall nicht einschätzen kann (nicht mein Server).

Jemand eine Idee, wie das umsetzbar ist? Im äußersten Notfall müsste ich wohl etwas coden, das sich nur auf Kernel-Routinen verlässt, aber vielleicht gibt's ja was von ratioph... Debian?

Danke und guten Rutsch!
Carsten

So wie Ich das sehe, machst die Sache komplizierter als sie eigentlich ist.
Denn diese Praxis mittels Erkennungsroutinen etwas zu finden, ist irgendwie sehr suboptimal mangels vorbeugender Wirkung. Also etwas erkennen zu wollen, wenn bereits eine Veränderung stattgefunden hat.
Dabei ist dein Anliegen doch ganz einfach: Du willst sicherstellen, dass dein Bootvorgang vertrauenswürdig abläuft, und im entgegengesetzten Fall informiert werden. So verstehe Ich den Kern der Aussage.

Die Lösung für dieses Problem, wären direkt als read-only eingebundene Volumes. Somit kann hier schon präventiv zu keiner Zeit etwas verändert werden, so lange eine schädliche Instanz nicht über Rootrechte verfügt, und ebenso betreffende Volumes als read-write neu eingebunden hat. Und solange der read-only Status besteht, ist der Datenbestand unberührt und vertrauenswürdig. Also muss man nur mittels eines Programms oder Shellscripts nach einem entsprechenden Mount-Ereignis suchen, bzw. direkt via Kernel-Interface danach Ausschau halten, und sobald so etwas eintritt wird eine definierte Gegenreaktion ausgelöst. Das kann ein Log-Eintrag sein, eine Desktop-Meldung, Eine Auflistung aller geänderter Dateien der letzten 10 Minuten, oder etwas Radikales wie die Initialisierung einer sofortigen Systemwiederherstellung. Denn nichts im System setzt diesen Status jemals zurück. Und wenn Du es nicht getan hast dann hast recht sicher etwas Schädliches an Bord, was versucht hier etwas zu verändern.

[MrScoville]

Danke für die vielen Anregungen und Ideen.

So langsam kann ich meinem Kollegen, der den vRoot betreibt, aber nur noch raten, den Anbieter zu wechseln. Nicht, weil ein überfürsorglicher Anbieter unbedingt die Konnektivität auch eines verbastelten Systems sicherstellen möchte, sondern eher weil dieser Anbieter dafür sorgen will um jeden Preis, dass DNS-Anfragen unbedingt über ausgerechnet 8.8.8.8 laufen sollen...

Ein Schelm, der "Google" dabei denkt...

[sbruder]

sondern eher weil dieser Anbieter dafür sorgen will um jeden Preis, dass DNS-Anfragen unbedingt über ausgerechnet 8.8.8.8 laufen sollen...

Um jeden Preis heißt für mich, dass er alle UDP/53-Verbindungen nicht routet außer die zu 8.8.8.8 (und 8.8.4.4). Wenn der Anbieter sowas macht, kann man das, was hinten rausfällt nicht mehr als Internet bezeichnen.