cgroup_namespaces(7) Miscellaneous Information Manual cgroup_namespaces(7)

cgroup_namespaces - Überblick über Linux-Cgroup-Namensräume

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

Cgroup-Namensräume virtualisieren den Blick auf die Cgroups eines Prozesses (siehe cgroups(7)), wie er mittels /proc/PID/cgroup und /proc/PID/mountinfo gesehen wird.

Jeder Cgroup-Namensraum hat seine eigene Gruppe an Cgroup-Wurzelverzeichnissen. Diese Wurzelverzeichnisse sind die Basispunkte der relativen Orte, die in den entsprechenden Datensätzen in der Datei /proc/PID/cgroup angezeigt werden. Wenn ein Prozess mittels clone(2) oder unshare(2) mit dem Schalter CLONE_NEWCGROUP einen neuen Cgroup-Namensraum erstellt, werden seine aktuellen Cgroup-Verzeichnisse das Cgroup-Wurzelverzeichnis des neuen Namensraumes. (Dies gilt sowohl für die Cgroup-Version-1-Hierarchien als auch die vereinigte Cgroup-Version-2-Hierarchie.)

Wenn die Cgroup-Mitgliedschaft eines »Ziel«-Prozesses aus /proc/PID/cgroup gelesen wird, wird der im dritten Feld jedes Datensatzes angezeigte Pfadname relativ zu dem Wurzelverzeichnis der entsprechenden Cgroup-Hierarchie des lesenden Prozesses sein. Falls das Cgroup-Verzeichnis des Zielprozesses außerhalb des Wurzelverzeichnisses des Cgroup-Namensraums des lesenden Prozesses liegt, dann wird der Pfadname ../-Einträge für jede Vorgängerstufe in der Cgroup-Hierarchie anzeigen.

Die folgende Shell-Sitzung zeigt die Auswirkung der Erstellung eines neuen Cgroup-Namensraumes.

Zuerst wird (als Systemverwalter) in einer Shell im anfänglichen Cgroup-Namensraum eine Nachfolger-Cgroup in der freezer-Hierarchie erstellt und ein Prozess in dieser Cgroup abgelegt, der als Teil der nachfolgenden Vorstellung verwandt wird:


# mkdir -p /sys/fs/cgroup/freezer/sub2
# sleep 10000 &     # Erzeugung eines Unterprozesses, der eine Zeit lebt
[1] 20124
# echo 20124 > /sys/fs/cgroup/freezer/sub2/cgroup.procs

Dann wird eine andere Cgroup in der freezer-Hierachie erstellt und die Shell in diese Gruppe versetzt:


# mkdir -p /sys/fs/cgroup/freezer/sub
# echo $$                      # PID dieser Shell zeigen
30655
# echo 30655 > /sys/fs/cgroup/freezer/sub/cgroup.procs
# cat /proc/self/cgroup | grep freezer
7:freezer:/sub

Als nächstes wird unshare(1) verwandt, um einen Prozess zu erzeugen, der in einer neuen Shell in dem neuen Cgroup- und Einhängenamensraum läuft:


# PS1="sh2# " unshare -Cm bash

Von der neuen durch unshare(1) gestarteten Shell werden dann die Dateien /proc/PID/cgroup der neuen Shell, eines Prozesse in dem anfänglichen Cgroup-Namensraum ((init mit PID 1) bzw. des Prozesses in der benachbarten Cgroup (sub2) untersucht:


sh2# cat /proc/self/cgroup | grep freezer
7:freezer:/
sh2# cat /proc/1/cgroup | grep freezer
7:freezer:/..
sh2# cat /proc/20124/cgroup | grep freezer
7:freezer:/../sub2

In der Ausgabe des ersten Befehls kann gesehen werden, dass die Freezer-Cgroup-Mitgliedschaft der neuen Shell (die in der gleichen Cgroup wie die anfängliche Shell ist) relativ zum Wurzelverzeichnis der Freezer-Cgroup definiert angezeigt wird, die etabliert wurde, als der neue Cgroup-Namensraum erstellt wurde. (Absolut gesehen ist die neue Shell in der Freezer-Cgroup /sub und das Wurzelverzeichnis der Freezer-Cgroup-Hierarchie in dem neuen Cgroup-Namensraum auch /sub. Daher wird die Cgroup-Mitgliedschaft der neuen Shell als »/« angezeigt.)

Wird allerdings in /proc/self/mountinfo geschaut, taucht folgende Anomalie auf:


sh2# cat /proc/self/mountinfo | grep freezer
155 145 0:32 /.. /sys/fs/cgroup/freezer …

Das vierte Feld dieser Zeile (/..) sollte das Verzeichnis in dem Cgroup-Dateisystem anzeigen, das die Wurzel dieser Einhängung formt. Da per Definition von Cgroup-Namensräumen das aktuelle Freezer-Cgroup-Verzeichnis des aktuellen Prozesses sein Wurzel-Freezer-Cgroup-Verzeichnis wurde, sollte in diesem Feld »/« auftauchen. Das Problem hier ist, dass ein Einhängeeintrag für das Cgroup-Dateisystem gezeigt wird, das dem anfänglichen Cgroup-Namensraum entspricht (dessen Cgroup-Dateisystem tatsächlich am übergeordneten Verzeichnis von sub verwurzelt ist). Um dieses Problem zu beheben, muss das Freezer-Cgroup-Dateisystem aus der neuen Shell neu eingehängt werden (d.h. die Einhängung muss von einem Prozess durchgeführt werden, der in dem neuen Cgroup-Namensraum ist). Danach kann das erwartete Ergebnis gesehen werden:


sh2# mount --make-rslave /     # Einhänge-Ereignisse nicht in
                               # andere Namensräume weiterleiten
sh2# umount /sys/fs/cgroup/freezer
sh2# mount -t cgroup -o freezer freezer /sys/fs/cgroup/freezer
sh2# cat /proc/self/mountinfo | grep freezer
155 145 0:32 / /sys/fs/cgroup/freezer rw,relatime …

Linux.

Die Verwendung von Cgroup-Namensräumen benötigt einen Kernel, der mit der Option CONFIG_CGROUPS konfiguriert ist.

Die durch Cgroup-Namensräume bereitgestellte Virtualisierung dient einer Reihe von Zwecken:

Sie verhindert Informationslecks, durch die Cgroup-Verzeichnispfade außerhalb eines Containers andernfalls für Prozesse innerhalb des Containers sichtbar sind. Solche Lecks könnten beispielsweise Informationen über das umgebende Container-System an Anwendungen innerhalb von Containern offenlegen.
Sie erleichtern Aufgaben wie Container-Migration. Die durch Cgroup-Namensräume bereitgestellte Virtualisierung erlaubt es, Container vom Wissen über die Pfadnamen von Vorgängern-Cgroups zu isolieren. Ohne solche Isolierungen müssten die vollständigen Cgroup-Pfadnamen (angezeigt in /proc/self/cgroups) auf dem Zielsystem bei der Migration eines Containers repliziert werden; diese Pfadnamen müssten auch eindeutig sein, so dass sie nicht zu anderen Pfadnamen auf dem Zielsystem in Konflikt stehen.
Sie erlauben bessere Einsperrungen von Prozessen in Containern, da es möglich ist, das Cgroup-Dateisystem des Containers so einzuhängen, dass der Prozess im Container keinen Zugriff auf die Vorgänger-Cgroup-Verzeichnisse erlangen kann. Betrachten Sie beispielsweise folgendes Szenario:
Es gibt ein Cgroup-Verzeichnis /cg/1, das der Benutzerkennung 9000 gehört.
Es gibt einen Prozess X, der auch der Benutzerkennung 9000 gehört, der im Namensraum unterhalb der Cgroup /cg/1/2 ist (d.h. X wurde in einen neuen Cgroup-Namensraum mittels clone(2) oder unshare(2) mit dem Schalter CLONE_NEWCGROUP gebracht).
Da das Cgroup-Verzeichnis /cg/1 der UID 9000 gehört (und für sie schreibbar ist) und X auch der UID 9000 gehört, wäre der Prozess X, in Abwesenheit von Cgroup-Namensräumen, in der Lage, die Inhalte der Cgroup-Dateien zu verändern (d.h. die Cgroup-Einstellungen zu ändern), nicht nur in /cg/1/2, sondern auch in dem Vorgänger-Cgroup-Verzeichnis /cg/1. Da der Prozess X im Namensraum unter dem Cgroup-Verzeichnis /cg/1/2 ist, wird, in Zusammenhang mit geeigneten Einhängeaktionen für das Cgroup-Dateisystem (wie oben gezeigt), verhindert, dass er Dateien in /cg/1 verändert, da er noch nicht einmal die Inhalte dieses Verzeichnisses (oder von weiter entfernten Cgroup-Vorgänger-Verzeichnissen) sehen kann. In Zusammenspiel mit der korrekten Durchsetzung von hierarchischen Beschränkungen verhindert dies, dass Prozess X diesen von den Vorgänger-Cgroups auferlegten Beschränkungen entkommt.

unshare(1), clone(2), setns(2), unshare(2), proc(5), cgroups(7), credentials(7), namespaces(7), user_namespaces(7)

Ü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.

31. Oktober 2023 Linux man-pages 6.06