Man page - pid_namespaces(7)

Packages contains this manual

Package: manpages
apt-get install manpages

Manuals in package:

Documentations in package:

manpages

Available languages:

en fr sv ja ru ro de

Manual

pid_namespaces

BEZEICHNUNG
BESCHREIBUNG
Der Init-Prozess des Namensraums
Verschachtelung von PID-Namensräumen
Semantik von setns und unshare(2)
Adoption von verwaisten Kindprozessen
Kompatibilität von CLONE_NEWPID zu anderen CLONE_*-Schaltern
/proc und PID-Namensräume
/proc-Dateien
Verschiedenes
STANDARDS
BEISPIELE
SIEHE AUCH
ÜBERSETZUNG

BEZEICHNUNG

pid_namespaces - Überblick über PID-Namensräume

BESCHREIBUNG

Für einen Überblick über Namensräume, siehe namespaces (7).

PID-Namensräume isolieren den Raum der Prozesskennungen. Das bedeutet, dass Prozesse in verschiedenen PID-Namensräumen die gleiche PID haben können. PID-Namensräume erlauben Containern, Funktionalitäten wie Suspendierung/Wiederaufnahme der Gruppe an Prozessen in dem Container und der Migration des Containers auf einen neuen Rechner bereitzustellen, bei denen die Prozesse innerhalb des Containers die gleiche PID behalten.

PIDs in einem neuen PID-Namensraum beginnen bei 1, ähnlich wie in autonomen Systemen. Aufrufe von fork (2), vfork (2) oder clone (2) werden Prozesse mit PIDs erstellen, die innerhalb des Namensraums eindeutig sind.

Die Verwendung von PID-Namensräumen benötigt einen Kernel, der mit der Option CONFIG_PID_NS konfiguriert wurde.

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_nfs (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.

STANDARDS

Linux.

BEISPIELE

siehe user_namespaces (7)

SIEHE AUCH

clone (2), reboot (2), setns (2), unshare (2), proc (5), capabilities (7), credentials (7), mount_namespaces (7), namespaces (7), user_namespaces (7), switch_root (8)

ÜBERSETZUNG

Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann <debian@helgefjell.de> erstellt.

Diese Übersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen.

Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Übersetzer: debian-l10n-german@lists.debian.org .