Können wir sagen, dass eine ganze "Reihe" von Dateien in einem Prozess (wie durch Dateideskriptoren dargestellt) diesen Prozess und mögliche Unterprozesse davon direkt widerspiegeln, so dass ein entsprechender Blick auf die durch die Dateideskriptoren beschriebenen Dateien möglich wäre Sagen Sie uns die genaue Art des Prozesses und mögliche Teilprozesse.
Wenn Sie sich also jede Datei ansehen (dargestellt durch Dateideskriptoren in einer entsprechenden Reihenfolge wie 0-X), können Sie dann die Art des Prozesses und / oder der Unterprozesse angeben?
Ich glaube, die Antwort wäre ja, wenn tatsächlich der gesamte Prozess nur aus diesen Dateien besteht.
Kurze Antwort: Nein
Lange Antwort: Die von einem Prozess verwendeten Dateideskriptoren sind nicht statisch genug, um eine zuverlässige Analyse des Prozesses zu ermöglichen. Dateien können geöffnet und geschlossen werden, die entsprechenden Datenstrukturen werden vom Kernel wiederverwendet.
Gegenbeispiel: Schreiben Sie zwei Programme, die beide etwa 100 Sekunden lang im Ruhezustand sind, und schreiben dann 1 bzw. 2 Sekunden. 2 bis stderr. Starten Sie beide von derselben Shell und stellen Sie sie in den Hintergrund. Sie können sie nicht anhand der Dateideskriptoren unterscheiden, die für beide identisch sind.
Variante: Lassen Sie dieselbe Datei öffnen, damit sie nicht funktioniert, wenn sie nicht auf die Standarddeskriptoren beschränkt ist.
Ich glaube nicht, dass ich genau verstehe, was Sie fragen ... Bitte fügen Sie eine Erklärung hinzu.
Aber von dem, was ich zu verstehen glaube, nein .
Eine Analogie könnte sein:
Wenn ich Person A beobachte und sehe, mit wem sie sprechen, kann ich dann die Absicht von Person A bestimmen?
In diesem Fall ist diese Antwort ziemlich trübe. Möglicherweise können Sie sehen, dass Person A mit einer wichtigen Person der Strafverfolgung und möglicherweise einigen Personen, die mit der organisierten Kriminalität in Verbindung stehen, spricht. Es wird jedoch extrem schwierig (unmöglich?), Die Motive von Person A mit Sicherheit zu bestimmen. Sind sie ein verdeckter Polizist oder ein Verbrecher mit einem Richter unter dem Daumen?
Sie können nichts verlässlich allein in dieses Wissen einlesen.
Wenn Sie weitere Informationen ermitteln konnten, z. B. die E / A, die ausgeführt wird, sind Sie auf dem besten Weg, die Situation klarer zu verstehen.
Wenn Sie sich also jede Datei ansehen (dargestellt durch Dateideskriptoren in einer entsprechenden Reihenfolge wie 0-X), können Sie dann die Art des Prozesses und / oder der Unterprozesse angeben?
Ich denke, Sie sind etwas verwirrt, was ein " Dateideskriptor " ist. Ein Dateideskriptor wird durch eine einfache Zahl ( int) - den Rückgabewert von open()... - identifiziert. Im Kernel sind jedoch einem Dateideskriptor Informationen zugeordnet. Siehe struct file.
Ich glaube, die Antwort wäre ja, wenn tatsächlich der gesamte Prozess nur aus diesen Dateien besteht.
Dies ist auch ein Beweis für ein Missverständnis. Ein Verfahren ist nicht „ aus nur diesen Dateien vorgenommen “, sondern stattdessen Zugriff auf diese Dateien jetzt . Wir können dies zeigen, indem Sie Folgendes ausführen:
$ ls -l /proc/self/fd total 0 lrwx------ 1 attie attie 64 May 20 15:20 0 -> /dev/pts/3 lrwx------ 1 attie attie 64 May 20 15:20 1 -> /dev/pts/3 lrwx------ 1 attie attie 64 May 20 15:20 2 -> /dev/pts/3 lr-x------ 1 attie attie 64 May 20 15:20 3 -> /proc/13103/fd Wie @grawity in einem Kommentar hervorgehoben hat, open()wird der nächste freie Dateideskriptor zurückgegeben, der etwaige Lücken von Null füllt. Was Sie oben sehen, ist eine Momentaufnahme der Dateien, die derzeit geöffnet sind und sich im Laufe der Zeit ändern.
Sie können die lsBinärdatei in der obigen Liste oder ihre unmittelbaren Abhängigkeiten nicht sehen:
$ ldd $(which ls) linux-vdso.so.1 => (0x00007fff569ef000) libselinux.so.1 => /lib/x86_64-linux-gnu/libselinux.so.1 (0x00007feeb33df000) libacl.so.1 => /lib/x86_64-linux-gnu/libacl.so.1 (0x00007feeb31d7000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007feeb2e0e000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007feeb2bd0000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007feeb29cc000) /lib64/ld-linux-x86-64.so.2 (0x00007feeb361a000) libattr.so.1 => /lib/x86_64-linux-gnu/libattr.so.1 (0x00007feeb27c6000) Wenn Sie versuchen, " auszuführenls ", liest der Linker tatsächlich die Bibliotheksdateien zum Sortieren und "Verknüpfen" des gesamten Prozessabbilds. Wenn die lsAusführung beginnt, sind diese Daten bereits im Speicher und die Dateien sind nicht mehr "offen".
Einige Anwendungen verwenden möglicherweise 'Plugins' oder laden 'dynamisch' zusätzliche Dateien, die Funktionalität bereitstellen (siehe dlopen()). Dies ist jedoch ein Randfall, der alles andere als typisch ist - keiner der Prozesse, die derzeit auf meinem Computer ausgeführt werden, verfügt über ein gemeinsames Objekt ( *.so) Datei öffnen.
Zusammenfassend und in Übereinstimmung mit meiner ursprünglichen Antwort, Nr .
Es gibt keine definitive Möglichkeit, das Verhalten eines Prozesses zu bestimmen, indem untersucht wird, welche Dateien geöffnet sind.
Das Bestimmen der Art eines Teilprozesses ist unmöglich - können Sie initdie vollständige Laufzeitkonfiguration eines Systems betrachten und bestimmen? Nein .
Kurze Antwort: Ja, aber sehr begrenzt.
In der Tat ist es eine der Hauptfunktionen eines Antivirenprogramms, die Funktionen eines Prozesses zu überwachen, da unter den geöffneten Dateien auch DLLs (Windows) oder gemeinsam genutzte Bibliotheken (Linux) enthalten sind. Ein Antivirusprogramm, das das Verhalten eines Prozesses beurteilt, löst Alarm aus, wenn ein Prozess zu viele oder zu vertrauliche Dateien öffnet oder versucht, auf vertrauliche Ordner zuzugreifen. Windows / Linux kann in solchen Fällen möglicherweise die Erlaubnis des Benutzers anfordern.
Es ist möglich zu erkennen, dass ein Prozess eine DLL / Shared-Library öffnet, aber um herauszufinden, welche APIs es aufruft, müssen die Systemaufrufe analysiert werden, die ein Antivirus-Programm finden kann, indem die ausführbare Datei des Prozesses untersucht wird .
Vergessen Sie nicht, dass die ausführbare Datei selbst eine der geöffneten Dateien ist, so dass ihre Analyse genau erkennen kann, welche DLLs / Shared-Libraries verwendet werden. Dies kann ein sehr gutes Verständnis dessen vermitteln.
Das Betriebssystem überwacht das Verhalten des Prozesses und klassifiziert es in einer Scheduling-Klasse als CPU-gebunden oder E / A-gebunden oder gemischt, was sich auf die Ausführungspriorität und die zulässigen Systemressourcen auswirkt.
Ein Unterprozess erbt normalerweise alle geöffneten Dateideskriptoren seines übergeordneten Elements und beginnt daher in der gleichen Klassifizierung in den Augen des Betriebssystems und des Antivirenprogramms, kann jedoch später durch seine Aktionen zu einer anderen Klassifizierung übergehen.
Nein.
Die meisten Prozesse haben ein sehr ähnliches Deskriptorverhalten. Beispielsweise schreiben fast alle Daemons ihre Ausgabe in Protokolle (Dateien), die häufig gemeinsam genutzt werden. Zum Beispiel auf meinem System /var/log/journalhat Einträge aus systemd, gnome-keyring-*, dbus-daemonund viele Programme.
Ein häufig verwendetes Muster ist das Umleiten von Deskriptoren zu / von /dev/oder das Schließen dieser.
Ein anderes Beispiel - cmpund im diffGrunde dasselbe, aber sie behandeln unterschiedliche Datentypen.
Es gibt sogar Programme in moreutilsPackage (was brillant ist), die einige gängige Deskriptormuster umschließen:
chronic - führt einen Befehl leise aus, sofern er nicht fehlschlägt sponge- Standardeingabe aufsaugen und in eine Datei schreiben (die Datei wird geöffnet, nachdem die Eingabe getränkt wurde, so dass grep "mom" somefile | sponge somefilenur die Zeilen in einer Datei verbleiben, die "mom" enthalten).diff).Und stellen Sie sich vor, wie schnell sich Deskriptoren topoder findProgramme ändern . Sie müssen sie während der gesamten Ausführungszeit nachverfolgen.
Eine Frage zum Mitnehmen: Was ist der Unterschied in den Deskriptoren zwischen LibreOffice Writer und GIMP (oder besser) sedund WannaCry?