Der Init-Prozess des Namensraums¶

Der erste in einem neuen Namensraum erstellte Prozess (d.h. der mittels clone(2) mit dem Schalter CLONE_NEWPID erstellte Prozess oder der erste Prozess, der durch einen Prozess nach einem Aufruf von unshare(2) mittels des Schalters CLONE_NEWPID erstellt wurde) hat die PID 1 und ist der »Init«-Prozess für den Namensraum (siehe init(1)). Dieser Prozess wird der Elternprozess jedes Kindprozesses, die verwaist wurden, da sich ein Prozess, der sich in diesem Namensraum befindet, beendet hat (weitere Details finden Sie weiter unten).

Falls sich der »Init«-Prozess eines PID-Namensraums beendet, beendet der Kernel mittels des Signals SIGKILL alle Prozesse in dem Namensraum. Dieses Verhalten spiegelt die Tatsache wieder, dass der »Init«-Prozess für das korrekte Funktionieren eines PID-Namensraums wesentlich ist. In diesem Fall wird ein nachfolgender fork(2) in den Namensraum mit dem Fehler ENOMEM fehlschlagen; es ist nicht möglich, einen neuen Prozess in einem PID-Namensraum zu erstellen, dessen »Init«-Prozess sich beendet hat. Solche Szenarien können auftreten, wenn beispielsweise ein Prozess einen offenen Dateideskriptor für eine Datei /proc/PID/ns/pid verwendet, der einem Prozess entspricht, der in einem Namensraum war und der mit setns(2) in einen Namensraum soll, nachdem sich der »Init«-Prozess beendet hat. Ein anderes mögliches Szenario kann direkt nach dem Aufruf von unshare(2) auftreten: Falls sich der erste Kindprozess, der nach einem fork(2) nachfolgend erstellt wurde, beendet, dann schlagen nachfolgende Aufrufe von fork(2) mit ENOMEM fehl.

Nur Signale, für die der »Init«-Prozess einen Signal-Handler etabliert hat, können durch andere Mitglieder des PID-Namensraums an den »Init«-Prozess gesandt werden. Diese Einschränkung gilt sogar für privilegierte Prozesse und verhindert, dass andere Mitglieder des PID-Namensraums versehentlich den »Init«-Prozess töten.

Entsprechend kann ein Prozess in einem Vorgängernamensraum – gemäß der gewöhnlichen, in kill(2) beschriebenen Berechtigungsprüfungen – nur Signale an den »Init«-Prozess eines Nachfolge-PID-Namensraums senden, falls der »Init«-Prozess einen Handler für das Signal etabliert hat. (Innerhalb des Handlers wird das sigaction(2) siginfo_t-Feld si_pid Null sein.) SIGKILL oder SIGSTOP werden besonders behandelt: diese Signale werden zwangsweise zugestellt, wenn sie von einem Vorgänger-PID-Namensraum gesandt werden. Keines dieser Signale kann durch den »Init«-Prozess abgefangen werden. Daher führen sie zu den gewöhnlichen Aktionen, die diesen Signalen zugeordnet sind (beenden bzw. stoppen des Prozesses).

Seit Linux 3.4 führt der Systemaufruf reboot(2) zum Senden eines Signales an den »Init«-Prozess des Namensraumes. Siehe reboot(2) für weitere Details.

Verschachtelung von PID-Namensräumen¶

PID-Namensräume können verschachtelt werden: jeder PID-Namensraum hat einen Vorgänger, außer für den anfänglichen (»Wurzel-«) PID-Namensraum. Der Vorgänger eines PID-Namensraums ist der PID-Namensraum des Prozesses, der den Namensraum mittels clone(2) oder unshare(2) erstellte. PID-Namensräume formen somit einen Baum, wobei alle Namensräume in letzter Instanz ihren Vorgänger auf den Wurzelnamensraum zurückführen. Seit Linux 3.7 begrenzt der Kernel die maximale Schachtelungstiefe für PID-Namensräume auf 32.

Ein Prozess ist für andere Prozesse in seinem PID-Namensraum sichtbar und für Prozesse in jedem direkten Vorgänger-PID-Namensraum, direkt zurück bis zum Wurzel-PID-Namensraum. In diesem Zusammenhang bedeutet »sichtbar«, dass ein Prozess das Ziel von Aktionen eines anderen Prozesses durch Verwendung von Systemaufrufen sein kann, die eine Prozesskennung angeben können. Umgekehrt kann ein Prozess in einem Nachfolge-PID-Namensraum die Prozesse in dem Vorgänger und weiter entfernten Vorgänger-Namensräumen nicht sehen. Kurz gesagt: Ein Prozess kann nur Prozesse, die in seinem eigenen PID-Namensraum und in Nachfolgern dieses Namensraums sind, sehen (z.B. ihnen Signale mit kill(2) senden, ihren Nice-Wert mit setpriority(2) ändern usw.).

Ein Prozess hat eine Prozesskennung in jedem der Ebenen der PID-Namensraum-Hierarchie, in der er sichtbar ist, sowie rückwärts durch jeden direkten Vorgängernamensraum bis zum Wurzel-PID-Namensraum. Systemaufrufe, die auf Prozesskennungen agieren, agieren immer auf Prozesskennungen, die in dem PID-Namensraum des aufrufenden Prozesses sichtbar sind. Ein Aufruf von getpid(2) liefert immer die PID zurück, die dem Namensraum zugeordnet ist, in dem der Prozess erstellt wurde.

Einige Prozesse in einem PID-Namensraum können Elternprozesse haben, die sich außerhalb des Namensraums befinden. Der Elternprozess des anfänglichen Prozesses in dem Namensraum (d.h. der init(1)-Prozess mit der PID 1) befindet sich beispielsweise notwendigerweise in einem anderen Namensraum. Entsprechend sind die direkten Kindprozesses eines Prozesses, der setns(2) verwendet, damit seine Kindprozesse einem PID-Namensraum beitreten, in einem anderen PID-Nemsraum als der Aufrufende von setns(2). Wird für solche Prozesse getppid(2) aufgerufen, dann wird 0 zurückgeliefert.

Während Prozesse frei in Nachfolge-PID-Namensräume absteigen können (z.B. mittels setns(2) mit einem PID-Namensraum-Dateideskriptor), können sie sich nicht in die andere Richtung bewegen. Das bedeutet, Prozesse dürfen keine Vorgängernamensräume (direkte, zweiter Stufe, usw.) betreten. Das Ändern von PID-Namensräumen ist eine Einwegaktion.

Die Aktion NS_GET_PARENT ioctl(2) kann zum Erkennen der hierarchischen Beziehung zwischen PID-Namensräumen verwandt werden; siehe ioctl_ns(2).

Semantik von setns und unshare(2)¶

Aufrufe von setns(2), die einen PID-Namensraum-Dateideskriptor festlegen und Aufrufe von unshare(2) mit dem Schalter CLONE_NEWPID führen dazu, dass nachfolgend durch den Aufrufenden erstellte Kindprozesse in einem anderen PID-Namensraum als dem des Aufrufenden abgelegt werden. (Seit Linux 4.12 wird dieser PID-Namensraum über die Datei /proc/PID/ns/pid_for_children gezeigt, wie in namespaces(7) beschrieben.) Diese Aufrufe ändern allerdings nicht den PID-Namensraum des aufrufenden Prozesses, da dies das Verständnis des Aufrufenden über seine eigene PID (wie sie mit getpid() berichtet wird) ändern würde, wodurch viele Anwendungen und Bibliotheken beschädigt würden.

Um es anders zu sagen: die Mitgliedschaft eines Prozesses in einem PID-Namensraum wird bei der Erstellung des Prozesses bestimmt und kann danach nicht mehr geändert werden. Unter anderem bedeutet dies, dass die Eltern-Kind-Beziehung zwischen Prozessen die Vorgänger-Nachfolger-Beziehung zwischen PID-Namensräumen spiegelt: der Elternprozess ist entweder im gleichen Namensraum oder befindet sich im direkten Vorgänger-PID-Namensraum.

Ein Prozess kann unshare(2) mit dem Schalter CLONE_NEWPID nur einmal aufrufen. Nachdem er diese Aktion durchgeführt hat, wird sein symbolischer Link /proc/PID/ns/pid_for_children leer sein, bis der erste Kindprozess in dem Namensraum erstellt wurde.

Adoption von verwaisten Kindprozessen¶

Wenn ein Kindprozess verwaist wird, wird der »Init«-Prozess in dem PID-Namensraum seines Elternprozesses sein neuer Elternprozess (außer einer der Vorfahrprozesse des Elternprozesses, der näher dran ist, setzt den Befehl prctl(2) PR_SET_CHILD_SUBREAPER ein, um sich selbst als Auffänger des verwaisten Nachfahrprozesses zu markieren.) Beachten Sie, dass aufgrund der oben beschriebenen Semantik von setns(2) und unshare(2) dies der »Init«-Prozess in dem PID-Namensraum sein kann, der Vorgänger des PID-Namensraums des Kindprozesses sein kann, statt des »Init«-Prozesses in dem eigenen PID-Namensraum des Kindprozesses.

Kompatibilität von CLONE_NEWPID zu anderen CLONE_*-Schaltern¶

In den aktuellen Versionen von Linux kann CLONE_NEWPID nicht mit CLONE_THREAD kombiniert werden. Threads müssen im gleichen PID-Namensraum sein, damit die Threads in einem Prozess sich gegenseitig Signale senden können. Entsprechend muss es möglich sein, alle Threads eines Prozesses in dem Dateisystem proc(5) zu sehen. Ergänzend kommt hinzu, dass die Prozesskennung des Prozesses, der ein Signal sendet, nicht beim Senden eines Signals aussagekräftig kodiert werden könnte, falls die zwei Threads in verschiedenen PID-Namensräumen wären (siehe die Beschreibung des Typs siginfo_t in sigaction(2)). Da diese berechnet wird, wenn ein Signal in die Warteschlange gestellt wird, würde eine Signalwarteschlange, die von Prozessen in mehreren PID-Namensräumen gemeinsam benutzt würde, dies vereiteln.

In früheren Versionen von Linux war zusätzlich CLONE_NEWPID verboten (schlug mit dem Fehler EINVAL fehl) zusammen mit CLONE_SIGHAND (vor Linux 4.3) sowie CLONE_VM (vor Linux 3.12). Die Änderungen, die diese Beschränkungen aufhoben, wurden auch in ältere stabile Kernel portiert.

/proc und PID-Namensräume¶

Ein Dateisystem /proc zeigt (in den Verzeichnissen /proc/PID) nur Prozesse, die in dem PID-Namensraum des Prozesses sichtbar sind, der die Einhängung durchführte, selbst falls das Dateisystem /proc von Prozessen in anderen Namensräumen betrachtet wird.

Nach dem Erstellen eines neuen PID-Namensraumes ist es für den Kindprozess nützlich, sein Wurzelverzeichnis zu ändern und eine neue Procfs-Instanz unter /proc einzuhängen, so dass Werkzeuge wie ps(1) korrekt funktionieren. Falls ein neuer Einhängenamensraum gleichzeitig durch Aufnahme von CLONE_NEWNS in dem Argument flags von clone(2) oder unshare(2) erstellt wird, dann ist es nicht notwendig, das Wurzelverzeichnis zu ändern: eine neue Procfs-Instanz kann direkt über /proc eingehängt werden.

In einer Shell lautet der Einhängebefehl für /proc:

$ mount -t proc proc /proc

Der Aufruf von readlink(2) auf dem Pfad /proc/self liefert die Prozesskennung des Aufrufenden in dem PID-Namensraum der Procfs-Einhängung (d.h. des PID-Namensraums, der Procfs einhängte). Dies kann zu Untersuchungszwecken nützlich sein, wenn ein Prozess seine PID in anderen Namensräumen herausfinden möchte.

/proc-Dateien¶

/proc/sys/kernel/ns_last_pid (seit Linux 3.3)

Diese Datei (die pro PID-Namensraum virtualisiert ist) zeigt die letzte PID, die in diesem PID-Namensraum zugewiesen wurde. Wenn die nächste PID zugewiesen wird, wird der Kernel nach der kleinsten nicht zugewiesenen PID suchen, die größer als dieser Wert ist, und wenn danach diese Datei gelesen wird, wird diese PID dann gezeigt.

Diese Datei ist für einen Prozess, der über die Capability CAP_SYS_ADMIN oder (seit Linux 5.9) CAP_CHECKPOINT_RESTORE innerhalb des Benutzernamensraums, der den PID-Namensraum besitzt, verfügt, schreibbar. Dies ermöglicht es, die PID zu bestimmen, die dem nächsten Prozess, der innerhalb des PID-Namensraums erstellt wird, zugewiesen wird.

Verschiedenes¶

Wenn eine Prozesskennung über einen UNIX-Domain-Socket an einen Prozess in einem anderen PID-Namensraum übergeben wird (siehe die Beschreibung von SCM_CREDENTIALS in unix(7)), dann wird sie in den entsprechenden PID-Wert in dem PID-Namensraum des empfangenen Prozesses übersetzt.