pid_namespaces(7) Miscellaneous Information Manual pid_namespaces(7) BEZEICHNUNG pid_namespaces - Uberblick uber PID-Namensraume BESCHREIBUNG Fur einen Uberblick uber Namensraume, siehe namespaces(7). PID-Namensraume isolieren den Raum der Prozesskennungen. Das bedeutet, dass Prozesse in verschiedenen PID-Namensraumen die gleiche PID haben konnen. PID-Namensraume erlauben Containern, Funktionalitaten 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, ahnlich 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-Namensraumen benotigt 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 fur 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 fur 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 moglich, einen neuen Prozess in einem PID-Namensraum zu erstellen, dessen >>Init<<-Prozess sich beendet hat. Solche Szenarien konnen auftreten, wenn beispielsweise ein Prozess einen offenen Dateideskriptor fur 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 mogliches 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, fur die der >>Init<<-Prozess einen Signal-Handler etabliert hat, konnen durch andere Mitglieder des PID-Namensraums an den >>Init<<-Prozess gesandt werden. Diese Einschrankung gilt sogar fur privilegierte Prozesse und verhindert, dass andere Mitglieder des PID-Namensraums versehentlich den >>Init<<-Prozess toten. Entsprechend kann ein Prozess in einem Vorgangernamensraum - gemass der gewohnlichen, in kill(2) beschriebenen Berechtigungsprufungen - nur Signale an den >>Init<<-Prozess eines Nachfolge-PID-Namensraums senden, falls der >>Init<<-Prozess einen Handler fur 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 Vorganger-PID-Namensraum gesandt werden. Keines dieser Signale kann durch den >>Init<<-Prozess abgefangen werden. Daher fuhren sie zu den gewohnlichen Aktionen, die diesen Signalen zugeordnet sind (beenden bzw. stoppen des Prozesses). Seit Linux 3.4 fuhrt der Systemaufruf reboot(2) zum Senden eines Signales an den >>Init<<-Prozess des Namensraumes. Siehe reboot(2) fur weitere Details. Verschachtelung von PID-Namensraumen PID-Namensraume konnen verschachtelt werden: jeder PID-Namensraum hat einen Vorganger, ausser fur den anfanglichen (>>Wurzel-<<) PID-Namensraum. Der Vorganger eines PID-Namensraums ist der PID-Namensraum des Prozesses, der den Namensraum mittels clone(2) oder unshare(2) erstellte. PID-Namensraume formen somit einen Baum, wobei alle Namensraume in letzter Instanz ihren Vorganger auf den Wurzelnamensraum zuruckfuhren. Seit Linux 3.7 begrenzt der Kernel die maximale Schachtelungstiefe fur PID-Namensraume auf 32. Ein Prozess ist fur andere Prozesse in seinem PID-Namensraum sichtbar und fur Prozesse in jedem direkten Vorganger-PID-Namensraum, direkt zuruck 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 konnen. Umgekehrt kann ein Prozess in einem Nachfolge-PID-Namensraum die Prozesse in dem Vorganger und weiter entfernten Vorganger-Namensraumen 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) andern usw.). Ein Prozess hat eine Prozesskennung in jedem der Ebenen der PID-Namensraum-Hierarchie, in der er sichtbar ist, sowie ruckwarts durch jeden direkten Vorgangernamensraum 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 zuruck, die dem Namensraum zugeordnet ist, in dem der Prozess erstellt wurde. Einige Prozesse in einem PID-Namensraum konnen Elternprozesse haben, die sich ausserhalb des Namensraums befinden. Der Elternprozess des anfanglichen 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 fur solche Prozesse getppid(2) aufgerufen, dann wird 0 zuruckgeliefert. Wahrend Prozesse frei in Nachfolge-PID-Namensraume absteigen konnen (z.B. mittels setns(2) mit einem PID-Namensraum-Dateideskriptor), konnen sie sich nicht in die andere Richtung bewegen. Das bedeutet, Prozesse durfen keine Vorgangernamensraume (direkte, zweiter Stufe, usw.) betreten. Das Andern von PID-Namensraumen ist eine Einwegaktion. Die Aktion NS_GET_PARENT ioctl(2) kann zum Erkennen der hierarchischen Beziehung zwischen PID-Namensraumen 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 fuhren 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 uber die Datei /proc/PID/ns/pid_for_children gezeigt, wie in namespaces(7) beschrieben.) Diese Aufrufe andern allerdings nicht den PID-Namensraum des aufrufenden Prozesses, da dies das Verstandnis des Aufrufenden uber seine eigene PID (wie sie mit getpid() berichtet wird) andern wurde, wodurch viele Anwendungen und Bibliotheken beschadigt wurden. 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 geandert werden. Unter anderem bedeutet dies, dass die Eltern-Kind-Beziehung zwischen Prozessen die Vorganger-Nachfolger-Beziehung zwischen PID-Namensraumen spiegelt: der Elternprozess ist entweder im gleichen Namensraum oder befindet sich im direkten Vorganger-PID-Namensraum. Ein Prozess kann unshare(2) mit dem Schalter CLONE_NEWPID nur einmal aufrufen. Nachdem er diese Aktion durchgefuhrt 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 (ausser einer der Vorfahrprozesse des Elternprozesses, der naher dran ist, setzt den Befehl prctl(2) PR_SET_CHILD_SUBREAPER ein, um sich selbst als Auffanger 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 Vorganger des PID-Namensraums des Kindprozesses sein kann, statt des >>Init<<-Prozesses in dem eigenen PID-Namensraum des Kindprozesses. Kompatibilitat von CLONE_NEWPID zu anderen CLONE_*-Schaltern In den aktuellen Versionen von Linux kann CLONE_NEWPID nicht mit CLONE_THREAD kombiniert werden. Threads mussen im gleichen PID-Namensraum sein, damit die Threads in einem Prozess sich gegenseitig Signale senden konnen. Entsprechend muss es moglich sein, alle Threads eines Prozesses in dem Dateisystem proc(5) zu sehen. Erganzend kommt hinzu, dass die Prozesskennung des Prozesses, der ein Signal sendet, nicht beim Senden eines Signals aussagekraftig kodiert werden konnte, falls die zwei Threads in verschiedenen PID-Namensraumen waren (siehe die Beschreibung des Typs siginfo_t in sigaction(2)). Da diese berechnet wird, wenn ein Signal in die Warteschlange gestellt wird, wurde eine Signalwarteschlange, die von Prozessen in mehreren PID-Namensraumen gemeinsam benutzt wurde, dies vereiteln. In fruheren Versionen von Linux war zusatzlich 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 Anderungen, die diese Beschrankungen aufhoben, wurden auch in altere stabile Kernel portiert. /proc und PID-Namensraume Ein Dateisystem /proc zeigt (in den Verzeichnissen /proc/PID) nur Prozesse, die in dem PID-Namensraum des Prozesses sichtbar sind, der die Einhangung durchfuhrte, selbst falls das Dateisystem /proc von Prozessen in anderen Namensraumen betrachtet wird. Nach dem Erstellen eines neuen PID-Namensraumes ist es fur den Kindprozess nutzlich, sein Wurzelverzeichnis zu andern und eine neue Procfs-Instanz unter /proc einzuhangen, so dass Werkzeuge wie ps(1) korrekt funktionieren. Falls ein neuer Einhangenamensraum 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 andern: eine neue Procfs-Instanz kann direkt uber /proc eingehangt werden. In einer Shell lautet der Einhangebefehl fur /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-Einhangung (d.h. des PID-Namensraums, der Procfs einhangte). Dies kann zu Untersuchungszwecken nutzlich sein, wenn ein Prozess seine PID in anderen Namensraumen herausfinden mochte. /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 nachste PID zugewiesen wird, wird der Kernel nach der kleinsten nicht zugewiesenen PID suchen, die grosser als dieser Wert ist, und wenn danach diese Datei gelesen wird, wird diese PID dann gezeigt. Diese Datei ist fur einen Prozess, der uber die Capability CAP_SYS_ADMIN oder (seit Linux 5.9) CAP_CHECKPOINT_RESTORE innerhalb des Benutzernamensraums, der den PID-Namensraum besitzt, verfugt, schreibbar. Dies ermoglicht es, die PID zu bestimmen, die dem nachsten Prozess, der innerhalb des PID-Namensraums erstellt wird, zugewiesen wird. Verschiedenes Wenn eine Prozesskennung uber einen UNIX-Domain-Socket an einen Prozess in einem anderen PID-Namensraum ubergeben 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 ubersetzt. 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) UBERSETZUNG Die deutsche Ubersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. Diese Ubersetzung ist Freie Dokumentation; lesen Sie die GNU General Public License Version 3 oder neuer bezuglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG ubernommen. Wenn Sie Fehler in der Ubersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die Mailingliste der Ubersetzer . Linux man-pages 6.9.1 13. Juni 2024 pid_namespaces(7)