.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2013 by Michael Kerrisk .\" and Copyright (c) 2012 by Eric W. Biederman .\" .\" SPDX-License-Identifier: Linux-man-pages-copyleft .\" .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH pid_namespaces 7 "13. Juni 2024" "Linux man\-pages 6.9.1" .SH BEZEICHNUNG pid_namespaces \- Überblick über PID\-Namensräume .SH BESCHREIBUNG Für einen Überblick über Namensräume, siehe \fBnamespaces\fP(7). .P 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. .P PIDs in einem neuen PID\-Namensraum beginnen bei 1, ähnlich wie in autonomen Systemen. Aufrufe von \fBfork\fP(2), \fBvfork\fP(2) oder \fBclone\fP(2) werden Prozesse mit PIDs erstellen, die innerhalb des Namensraums eindeutig sind. .P .\" .\" ============================================================ .\" Die Verwendung von PID\-Namensräumen benötigt einen Kernel, der mit der Option \fBCONFIG_PID_NS\fP konfiguriert wurde. .SS "Der Init\-Prozess des Namensraums" Der erste in einem neuen Namensraum erstellte Prozess (d.h. der mittels \fBclone\fP(2) mit dem Schalter \fBCLONE_NEWPID\fP erstellte Prozess oder der erste Prozess, der durch einen Prozess nach einem Aufruf von \fBunshare\fP(2) mittels des Schalters \fBCLONE_NEWPID\fP erstellt wurde) hat die PID 1 und ist der »Init«\-Prozess für den Namensraum (siehe \fBinit\fP(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). .P Falls sich der »Init«\-Prozess eines PID\-Namensraums beendet, beendet der Kernel mittels des Signals \fBSIGKILL\fP 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 \fBfork\fP(2) in den Namensraum mit dem Fehler \fBENOMEM\fP 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 \fI/proc/\fPPID\fI/ns/pid\fP verwendet, der einem Prozess entspricht, der in einem Namensraum war und der mit \fBsetns\fP(2) in einen Namensraum soll, nachdem sich der »Init«\-Prozess beendet hat. Ein anderes mögliches Szenario kann direkt nach dem Aufruf von \fBunshare\fP(2) auftreten: Falls sich der erste Kindprozess, der nach einem \fBfork\fP(2) nachfolgend erstellt wurde, beendet, dann schlagen nachfolgende Aufrufe von \fBfork\fP(2) mit \fBENOMEM\fP fehl. .P 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. .P Entsprechend kann ein Prozess in einem Vorgängernamensraum \[en] gemäß der gewöhnlichen, in \fBkill\fP(2) beschriebenen Berechtigungsprüfungen \[en] 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 \fBsigaction\fP(2) \fIsiginfo_t\fP\-Feld \fIsi_pid\fP Null sein.) \fBSIGKILL\fP oder \fBSIGSTOP\fP 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). .P .\" .\" ============================================================ .\" Seit Linux 3.4 führt der Systemaufruf \fBreboot\fP(2) zum Senden eines Signales an den »Init«\-Prozess des Namensraumes. Siehe \fBreboot\fP(2) für weitere Details. .SS "Verschachtelung von PID\-Namensräumen" .\" commit f2302505775fd13ba93f034206f1e2a587017929 .\" The kernel constant MAX_PID_NS_LEVEL 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 \fBclone\fP(2) oder \fBunshare\fP(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. .P 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 \fBkill\fP(2) senden, ihren Nice\-Wert mit \fBsetpriority\fP(2) ändern usw.). .P 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 \fBgetpid\fP(2) liefert immer die PID zurück, die dem Namensraum zugeordnet ist, in dem der Prozess erstellt wurde. .P 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 \fBinit\fP(1)\-Prozess mit der PID 1) befindet sich beispielsweise notwendigerweise in einem anderen Namensraum. Entsprechend sind die direkten Kindprozesses eines Prozesses, der \fBsetns\fP(2) verwendet, damit seine Kindprozesse einem PID\-Namensraum beitreten, in einem anderen PID\-Nemsraum als der Aufrufende von \fBsetns\fP(2). Wird für solche Prozesse \fBgetppid\fP(2) aufgerufen, dann wird 0 zurückgeliefert. .P Während Prozesse frei in Nachfolge\-PID\-Namensräume absteigen können (z.B. mittels \fBsetns\fP(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. .P .\" .\" ============================================================ .\" Die Aktion \fBNS_GET_PARENT\fP \fBioctl\fP(2) kann zum Erkennen der hierarchischen Beziehung zwischen PID\-Namensräumen verwandt werden; siehe \fBioctl_nfs\fP(2). .SS "Semantik von setns und unshare(2)" Aufrufe von \fBsetns\fP(2), die einen PID\-Namensraum\-Dateideskriptor festlegen und Aufrufe von \fBunshare\fP(2) mit dem Schalter \fBCLONE_NEWPID\fP 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 \fI/proc/\fPPID\fI/ns/pid_for_children\fP gezeigt, wie in \fBnamespaces\fP(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 \fBgetpid\fP() berichtet wird) ändern würde, wodurch viele Anwendungen und Bibliotheken beschädigt würden. .P 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. .P .\" .\" ============================================================ .\" Ein Prozess kann \fBunshare\fP(2) mit dem Schalter \fBCLONE_NEWPID\fP nur einmal aufrufen. Nachdem er diese Aktion durchgeführt hat, wird sein symbolischer Link \fI/proc/\fPPID\fI/ns/pid_for_children\fP leer sein, bis der erste Kindprozess in dem Namensraum erstellt wurde. .SS "Adoption von verwaisten Kindprozessen" .\" Furthermore, by definition, the parent of the "init" process .\" of a PID namespace resides in the parent PID namespace. .\" .\" ============================================================ .\" 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 \fBprctl\fP(2) \fBPR_SET_CHILD_SUBREAPER\fP ein, um sich selbst als Auffänger des verwaisten Nachfahrprozesses zu markieren.) Beachten Sie, dass aufgrund der oben beschriebenen Semantik von \fBsetns\fP(2) und \fBunshare\fP(2) dies der »Init«\-Prozess in dem PID\-Namensraum sein kann, der \fIVorgänger\fP des PID\-Namensraums des Kindprozesses sein kann, statt des »Init«\-Prozesses in dem eigenen PID\-Namensraum des Kindprozesses. .SS "Kompatibilität von CLONE_NEWPID zu anderen CLONE_*\-Schaltern" In den aktuellen Versionen von Linux kann \fBCLONE_NEWPID\fP nicht mit \fBCLONE_THREAD\fP 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 \fBproc\fP(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 \fIsiginfo_t\fP in \fBsigaction\fP(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. .P .\" Note these restrictions were all introduced in .\" 8382fcac1b813ad0a4e68a838fc7ae93fa39eda0 .\" when CLONE_NEWPID|CLONE_VM was disallowed .\" (restriction lifted in faf00da544045fdc1454f3b9e6d7f65c841de302) .\" (restriction lifted in e79f525e99b04390ca4d2366309545a836c03bf1) .\" .\" ============================================================ .\" In früheren Versionen von Linux war zusätzlich \fBCLONE_NEWPID\fP verboten (schlug mit dem Fehler \fBEINVAL\fP fehl) zusammen mit \fBCLONE_SIGHAND\fP (vor Linux 4.3) sowie \fBCLONE_VM\fP (vor Linux 3.12). Die Änderungen, die diese Beschränkungen aufhoben, wurden auch in ältere stabile Kernel portiert. .SS "/proc und PID\-Namensräume" Ein Dateisystem \fI/proc\fP zeigt (in den Verzeichnissen \fI/proc/\fPPID) nur Prozesse, die in dem PID\-Namensraum des Prozesses sichtbar sind, der die Einhängung durchführte, selbst falls das Dateisystem \fI/proc\fP von Prozessen in anderen Namensräumen betrachtet wird. .P 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 \fI/proc\fP einzuhängen, so dass Werkzeuge wie \fBps\fP(1) korrekt funktionieren. Falls ein neuer Einhängenamensraum gleichzeitig durch Aufnahme von \fBCLONE_NEWNS\fP in dem Argument \fIflags\fP von \fBclone\fP(2) oder \fBunshare\fP(2) erstellt wird, dann ist es nicht notwendig, das Wurzelverzeichnis zu ändern: eine neue Procfs\-Instanz kann direkt über \fI/proc\fP eingehängt werden. .P In einer Shell lautet der Einhängebefehl für \fI/proc\fP: .P .in +4n .EX $ mount \-t proc proc /proc .EE .in .P .\" .\" ============================================================ .\" Der Aufruf von \fBreadlink\fP(2) auf dem Pfad \fI/proc/self\fP 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. .SS /proc\-Dateien .TP \fB/proc/sys/kernel/ns_last_pid\fP (seit Linux 3.3) .\" commit b8f566b04d3cddd192cfd2418ae6d54ac6353792 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. .IP .\" This ability is necessary to support checkpoint restore in user-space .\" .\" ============================================================ .\" Diese Datei ist für einen Prozess, der über die Capability \fBCAP_SYS_ADMIN\fP oder (seit Linux 5.9) \fBCAP_CHECKPOINT_RESTORE\fP 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. .SS Verschiedenes Wenn eine Prozesskennung über einen UNIX\-Domain\-Socket an einen Prozess in einem anderen PID\-Namensraum übergeben wird (siehe die Beschreibung von \fBSCM_CREDENTIALS\fP in \fBunix\fP(7)), dann wird sie in den entsprechenden PID\-Wert in dem PID\-Namensraum des empfangenen Prozesses übersetzt. .SH STANDARDS Linux. .SH BEISPIELE siehe \fBuser_namespaces\fP(7) .SH "SIEHE AUCH" \fBclone\fP(2), \fBreboot\fP(2), \fBsetns\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBmount_namespaces\fP(7), \fBnamespaces\fP(7), \fBuser_namespaces\fP(7), \fBswitch_root\fP(8) .PP .SH ÜBERSETZUNG Die deutsche Übersetzung dieser Handbuchseite wurde von Helge Kreutzmann erstellt. .PP Diese Übersetzung ist Freie Dokumentation; lesen Sie die .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License Version 3 .UE oder neuer bezüglich der Copyright-Bedingungen. Es wird KEINE HAFTUNG übernommen. .PP Wenn Sie Fehler in der Übersetzung dieser Handbuchseite finden, schicken Sie bitte eine E-Mail an die .MT debian-l10n-german@lists.debian.org Mailingliste der Übersetzer .ME .