Provided by: manpages-de_4.13-4_all 
BEZEICHNUNG
mount_namespaces - Überblick über Linux-Einhänge-Namensräume
BESCHREIBUNG
Für einen Überblick über Namensräume, siehe namespaces(7).
Einhängenamensräume bieten eine Isolierung der Liste der von Prozessen in jeder
Namensrauminstanz gesehenen Einhängepunkten. Daher wird jeder Prozess in jeder der
Einhänge-Namensrauminstanzen eine individuelle Einzelverzeichnis-Hierarchie sehen.
Die von den Dateien /proc/[PID]/mounts, /proc/[PID]/mountinfo und /proc/[PID]/mountstats
(alle In proc(5) beschrieben) bereitgestellten Ansichten entsprechen den
Einhängenamensräumen, in denen sich der Prozess mit der PID [PID] befindet. (Alle
Prozesse, die sich in dem gleichen Einhängenamensraum befinden, werden die gleiche Ansicht
auf diese Dateien sehen.)
Ein neuer Einhängenamensraum wird entweder mittels clone(2) oder mittels unshare(2) mit
dem Schalter CLONE_NEWNS erstellt. Wenn ein neuer Einhängenamensraum erstellt wird, wird
seine Einhängepunktliste wie folgt initialisiert:
* Falls der Namensraum mittels clone(2) erstellt wurde, ist die Einhängepunktliste des
Nachfolgenamensraums eine Kopie der Einhängepunktliste des Vorgängernamensraums.
* Falls der Namensraum mittels unshare(2) erstellt wurde, ist die Einhängepunktliste des
neuen Namensraums eine Kopie der Einhängepunktliste in dem vorherigen Namensraum des
aufrufenden Prozesses.
Nachfolgende Änderungen an der Einhängepunktliste (mount(2) und umount(2)) in jedem der
Namensräume wird (standardmäßig) die Einhängepunktliste, die in den anderen Namensräumen
gesehen wird, nicht betreffen (lesen Sie allerdings auch die nachfolgende Diskussion von
gemeinsamen Unterbäumen).
Beschränkungen für Einhängenamensräume
Beachten Sie die folgenden Punkte in Hinblick auf Einhängenamensräume:
* Jeder Einhängenamensraum hat einen Eigentümer-Benutzernamensraum. Wie oben beschrieben
wird beim Erstellen eines neuen Einhängenamensraumes seine Einhängepunktliste als Kopie
der Einhängepunktliste eines anderen Einhängenamensraums initialisiert. Falls der neue
Namensraum und der Namensraum, von dem die Einhängepunktliste kopiert wurde,
verschiedenen Benutzernamensräumen gehören, dann wird der neue Einhängenamensraum als
weniger privilegiert betrachtet.
* Beim Erstellen eines weniger privilegierten Einhängenamensraums werden gemeinsame
Einhängungen zu abhängigen Einhängungen reduziert. (Gemeinsame und abhängige
Einhängungen werden weiter unten diskutiert.) Dies stellt sicher, dass Abbildungen, die
in weniger privilegierten Namensräumen erfolgen, nicht in mehr privilegierte
Namensräume weitergeleitet werden.
* Einhängungen, die als gemeinsame Einheit von einem mehr privilegierten
Einhängenamensraum kommen, werden zusammengeklemmt und können in einem weniger
privilegierten Namensraum nicht getrennt werden. (Die Aktion unshare(2) CLONE_NEWNS
bringt alle Einhängungen von dem ursprünglichen Einhängenamensraum als gemeinsame
Einheit herüber und rekursive Einhängungen, die zwischen Einhängenamensräumen
weiterleiten, werden als gemeinsame Einheit weitergeleitet.)
* Die Schalter MS_RDONLY, MS_NOSUID, MS_NOEXEC von mount(2) und die
»atime«-Schalter-Einstellungen (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) werden
geklemmt, wenn sie von einem mehr privilegierten in einen weniger privilegierten
Einhängenamensraum weitergeleitet werden und dürfen in dem weniger privilegierten
Namensraum nicht geändert werden.
* Eine Datei oder ein Verzeichnis, das ein Einhängepunkt in einem Namensraum ist, der
kein Einhängepunkt in einem anderen Namensraum ist, kann umbenannt, mit der Funktion
»unlink« gelöscht oder in dem Einhängenamensraum, in dem er kein Einhängepunkt ist,
gelöscht (rmdir(2)) werden (abhängig von den normalen Berechtigungsprüfungen).
Konsequenterweise wird der Einhängepunkt in dem Einhängenamensraum, in dem er ein
Einhängepunkt war, entfernt.
Früher (vor Linux 3.18) führte der Versuch, eine Datei oder ein Verzeichnis, das ein
Einhängepunkt in einem anderen Namensraum war, mit »unlink« zu löschen, umzubenennen
oder zu entfernen zu dem Fehler EBUSY. Dieses Verhalten hatte technische Probleme bei
der Durchsetzung (z.B. für NFS) und ermöglichte Diensteverweigerungsangriffe gegen mehr
privilegierte Benutzer (d.h. Verhinderung von der Aktualisierung einzelner Dateien
durch Einhängungen mit der Option bind darüber).
GEMEINSAME UNTERBÄUME
Nachdem die Implementierung von Einhängenamensräumen abgeschlossen war, zeigte die
Erfahrung, dass die bereitgestellte Isolierung in einigen Fällen zu weit ging. Um
beispielsweise eine frisch geladene optische Platte in allen Einhängenamensräumen zur
Verfügung zu stellen, war in jedem der Namensräume eine Einhängeaktion notwendig. Für
diesen und andere Anwendungsfälle wurde die Funktionalität gemeinsamer Unterbäume in Linux
2.6.15 eingeführt. Diese Funktionalität erlaubt die automatische, kontrollierte
Weiterleitung von Einhänge- und Aushänge-Ereignissen zwischen Namensräumen (oder, genauer,
zwischen Mitgliedern einer Gemeinschaftsgruppe, die Ereignisse aneinander weiterleiten).
Jeder Einhängepunkt wird (über mount(2)) markiert, dass er einen der folgenden
Weiterleitungstypen hat:
MS_SHARED
Dieser Einhängepunkt nutzt Ereignisse mit Mitgliedern der Gemeinschaftsgruppe
gemeinsam. Einhänge- und Aushängeereignisse direkt unterhalb dieses Einhängepunktes
werden zu den anderen Einhängepunkten, die Mitglied dieser Gemeinschaftsgruppe
sind, weitergeleitet. Weiterleitung bedeutet hier, dass die gleiche Ein- oder
Aushängung unter allen diesen Einhängepunkten in der Gemeinschaftsgruppe
automatisch erfolgen wird. Entsprechend werden Ein- und Aushängungen, die unter
anderen Einhängepunkten der Gruppe stattfinden, zu diesem Einhängepunkt
weitergeleitet.
MS_PRIVATE
Dieser Einhängepunkt ist privat; er ist in keiner Gemeinschaftsgruppe. Ein- oder
Aushängeereignisse werden nicht aus diesem Einhängepunkt heraus oder in ihn hinein
weitergeleitet.
MS_SLAVE
Ein- und Aushängeereignisse werden in diesen Einhängepunkt von einer übergeordneten
(Master-) Gemeinschaftsgruppe weitergeleitet. Ein- und Aushängungen unterhalb
dieses Einhängepunktes werden nicht zu anderen Mitgliedern der Gruppe
weitergeleitet.
Beachten Sie, dass ein Einhängepunkt ein Abhängiger von einer anderen
Gemeinschaftsgruppe sein kann und gleichzeitig ein Mitglied in einer zweiten
Gemeinschaftsgruppe sein kann, an die und von der er Ein- und Aushängeereignisse
sendet bzw. empfängt. (Genauer gesagt kann eine Gemeinschaftsgruppe eine Abhängige
einer anderen Gemeinschaftsgruppe sein).
MS_UNBINDABLE
Dies ist wie eine private Einhängung und zusätzlich kann diese Einhängung nicht mit
der Option bind erfolgen. Wird versucht, diese Einhängung mit der Option bind
einzuhängen (mount(2) mit dem Schalter MS_BIND), dann schlägt dies fehl.
Wenn eine rekursive Einhängung mit der Option bind (mount(2) mit den Schaltern
MS_BIND und MS_REC) auf einem Verzeichnisunterbaum erfolgt, werden alle
Einhängungen mit der Option bind innerhalb des Unterbaums automatisch abgeschnitten
(d.h. nicht repliziert), wenn der Unterbaum repliziert wird, um den Ziel-Unterbaum
zu erstellen.
Bitte lesen Sie die HINWEISE für eine Diskussion der Weiterleitungstypen, die einer neuen
Einhängung zugeordnet sind.
Der Weiterleitungstyp ist eine einhängungsbezogene Einstellung: einige Einhängepunkte
könnten als gemeinsam gekennzeichnet sein (wobei jeder gemeinsame Einhängepunkt ein
Mitglied einer unterschiedlichen Gemeinschaftsgruppe ist), während andere privat (oder
abhängig oder nicht-Bind-fähig) sind.
Beachten Sie, dass der Weiterleitungstyp einer Einhängung bestimmt, ob Ein- und
Aushängungen direkt unter dem Einhängepunkt weitergeleitet werden. Daher betrifft der
Einhängungstyp nicht die Weiterleitung von Ereignissen für weiter unten liegende
Einhängungen. Was passiert, wenn der Einhängepunkt selbst ausgehängt wird, wird durch den
Weiterleitungstyp bestimmt, der für den übergeordneten Einhängepunkt wirksam ist.
Mitglieder werden zu einer Gemeinschaftsgruppe hinzugefügt, wenn ein Einhängepunkt als
gemeinsam markiert ist und entweder:
* der Einhängepunkt während der Erstellung eines neuen Einhängenamensraumes repliziert
wird; oder
* eine neue Einhängung mit der Option bind von diesem Einhängepunkt erstellt wird.
In beiden Fällen tritt der neue Einhängepunkt der Gemeinschaftsgruppe bei, bei der der
bestehende Einhängepunkt bereits Mitglied ist.
Eine neue Gemeinschaftsgruppe wird auch erstellt, wenn ein nachfolgender Einhängepunkt
unter einem bestehenden Einhängepunkt, der als gemeinsam markiert ist, erstellt wird. In
diesem Fall wird der nachfolgende Einhängepunkt als gemeinsam markiert und die entstehende
Gemeinschaftsgruppe besteht aus allen Einhängepunkten, die unterhalb der Mitglieder der
übergeordneten Einhängung repliziert werden.
Eine Einhängung hört auf, Mitglied einer Gemeinschaftsgruppe zu sein, wenn die Einhängung
entweder explizit ausgehängt wird oder wenn die Einhängung implizit ausgehängt wird, da
der Einhängenamensraum entfernt wird (da er keinen Mitgliedsprozess mehr hat).
Der Weiterleitungstyp des Einhängepunktes in einem Einhängenamensraum kann mittels der
»optionalen Felder« in /proc/[PID]/mountinfo offengelegt werden. (Siehe proc(5) für
Details zu dieser Datei.) Die folgenden Markierungen können in den optionalen Feldern für
einen Datensatz in dieser Datei auftauchen:
shared:X
Dieser Einhängepunkt wird in der Gemeinschaftsgruppe X gemeinsam benutzt. Jede
Gemeinschaftsgruppe hat eine eindeutige Kennung, die durch den Kernel automatisch
erstellt wird. Alle Einhängepunkte in der gleichen Gemeinschaftsgruppe werden die
gleiche Kennung zeigen. (Diese Kennungen werden beginnend mit dem Wert 1 zugewiesen
und können wiederbenutzt werden, wenn eine Gemeinschaftsgruppe keine Mitglieder
mehr hat.)
master:X
Diese Einhängung ist eine Abhängige der gemeinsamen Gemeinschaftsgruppe X.
propagate_from:X (seit Linux 2.6.26)
Diese Einhängung ist eine Abhängige und empfängt Weiterleitungen von der
gemeinsamen Gemeinschaftsgruppe X. Diese Markierung wird immer zusammen mit einer
Markierung master:X auftauchen. Hier ist X die naheliegendste dominante
Gemeinschaftsgruppe unter dem Wurzelverzeichnis des Prozesses. Falls X der direkte
Master der Einhängung ist oder falls es keine dominante Gemeinschaftsgruppe
unterhalb der gleichen Wurzel gibt, dann ist nur das Feld master:X und nicht das
Feld propagate_from:X vorhanden. Weitere Details folgen weiter unten.
unbindable
Dies ist eine nicht-bind-fähige Einhängung.
Falls keine der obigen Markierungen vorhanden ist, dann ist dies eine private Einhängung.
Beispiel für MS_SHARED und MS_PRIVATE
Nehmen wir an, das wir im Terminal des anfänglichen Einhängenamensraums einen
Einhängepunkt als gemeinsam und einen anderen als privat markieren, und uns dann die
Einhängungen in /proc/self/mountinfo anschauen:
sh1# mount --make-shared /mntS
sh1# mount --make-private /mntP
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime
In der Ausgabe in /proc/self/mountinfo können wir sehen, dass /mntS eine gemeinsame
Einhängung in der Gemeinschaftsgruppe 1 ist und dass /mntP keine optionale Markierungen
hat und damit anzeigt, dass es eine private EInhängung ist. Die ersten zwei Felder in
jedem Datensatz in dieser Datei sind die eindeutige Kennung für diese Einhängung und die
Einhängungskennung der Elterneinhängung. Wir können diese Datei weiter untersuchen, um zu
sehen, dass der Elterneinhängepunkt von /mntS und /mntP das Wurzelverzeichnis / ist, das
privat eingehängt wurde:
sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
61 0 8:2 / / rw,relatime
In einem zweiten Terminal erstellen wir einen neuen Einhängenamensraum, in dem wir eine
zweite Shell ausführen und die Einhängungen untersuchen:
$ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime
Der neue Einhängenamensraum erhielt eine Kopie der Einhängepunkte des anfänglichen
Einhängenamensraumes. Diese neuen Einhängepunkte behalten die gleichen Weiterleitungstypen
bei, haben aber eindeutige Einhängekennungen. (Die Option --propagation unchanged
verhindert, dass unshare(1) alle Einhängungen als privat markiert, wenn ein neuer
Einhängenamensraum erstellt wird, wie er es sonst standardmäßig machen würde.)
In dem zweiten Terminal erstellen wir jetzt Untereinhängungen unter sowohl /mntS als auch
/mntP und untersuchen das Ergebnis:
sh2# mkdir /mntS/a
sh2# mount /dev/sdb6 /mntS/a
sh2# mkdir /mntP/b
sh2# mount /dev/sdb7 /mntP/b
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
222 145 8:17 / /mntS rw,relatime shared:1
225 145 8:15 / /mntP rw,relatime
178 222 8:22 / /mntS/a rw,relatime shared:2
230 225 8:23 / /mntP/b rw,relatime
In obiger Ausgabe kann erkannt werden, dass /mntS/a als gemeinsame Einhängung (die
Einstellung wurde von der Elterneinhängung übernommen) und /mntP/b als private Einhängung
erstellt wurde.
Wird zum ersten Terminal zurückgekehrt und das Ergebnis untersucht, können wir sehen, dass
die neue Einhängung, die unterhalb des gemeinsamenen Einhängepunkts /mntS erstellt wurde,
an die Einhängungen in seiner Gemeinschaftsgruppe weitergeleitet wurde (im anfänglichen
Einhängenamensraum), aber die Einhängung, die unter dem privaten Einhängepunkt /mntP
erstellt wurde, nicht weitergeleitet wurde:
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
77 61 8:17 / /mntS rw,relatime shared:1
83 61 8:15 / /mntP rw,relatime
179 77 8:22 / /mntS/a rw,relatime shared:2
MS_SLAVE-Beispiel
Wird ein Einhängepunkt ein Abhängiger, ist es möglich, weitergeleitete Ein- und
Aushängeereignisse von einer gemeinsamen Master-Gemeinschaftsgruppe zu erhalten und
zugleich sie daran zu hindern, Ereignisse zu diesem Master weiterzuleiten. Dies ist
nützlich, wenn Sie (beispielsweise) ein Einhängeereignis erhalten möchten, wenn eine
optische Platte in der gemeinsamen Gemeinschaftsgruppe des Masters eingehängt wird (in
einem anderen Einhängenamensraum), aber Sie verhindern möchten, dass Ein- und
Aushängeereignisse unter der Einhängung der Abhängigen zu Seiteneffekten in anderen
Namensräumen führen.
Wir zeigen die Auswirkung der Abhängigen, indem wir zuerst zwei Einhängepunkte als
gemeinsam im anfänglichen Namensraum markieren:
sh1# mount --make-shared /mntX
sh1# mount --make-shared /mntY
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
Auf einem zweiten Terminal erstellen wir einen neuen Einhängenamensraum und untersuchen
die Einhängepunkte:
sh2# unshare -m --propagation unchanged sh
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime shared:2
In dem neuen Einhängenamensraum können wir einen Einhängepunkt als Abhängigen markieren:
sh2# mount --make-slave /mntY
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
Aus der obigen Ausgabe kann gesehen werden, dass /mntY jetzt eine abhängige Einhängung
ist, die Weiterleitungsereignisse von der gemeinsamen Gemeinschaftsgruppe mit der Kennung
2 erhält.
Im neuen Namensraum wird jetzt fortgefahren und Untereinhängungen unter sowohl /mntX als
auch /mntY erstellt:
sh2# mkdir /mntX/a
sh2# mount /dev/sda3 /mntX/a
sh2# mkdir /mntY/b
sh2# mount /dev/sda5 /mntY/b
Wenn wir den Zustand der Einhängepunkte in den neuen Einhängenamensräumen untersuchen,
sehen wir, dass /mntX/a als eine neue gemeinsame Einhängung erstellt wurde (die die
Einstellung »shared« ihrer Elterneinhängung geerbt hat) und dass /mntY/b als eine private
Einhängung erstellt wurde:
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime
Zurück im ersten Terminal (im anfänglichen Einhängenamensraum) sehen wir, dass die
Einhängung /mntX/a zu dem Mitglied der Gemeinschaftsgruppe weitergeleitet wurde (der
gemeinsame /mntX), aber dass die Einhängung /mntY/b nicht weitergeleitet wurde:
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3
Jetzt erstellen wir eine neuen Einhängepunkt unter /mntY in der ersten Shell:
sh1# mkdir /mntY/c
sh1# mount /dev/sda1 /mntY/c
sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
132 83 8:23 / /mntX rw,relatime shared:1
133 83 8:22 / /mntY rw,relatime shared:2
174 132 8:3 / /mntX/a rw,relatime shared:3
178 133 8:1 / /mntY/c rw,relatime shared:4
Wenn wir die Einhängepunkte in dem zweiten Einhängenamensraum untersuchen, sehen wir, dass
in diesem Fall die Einhängung zu dem abhängigen Einhängepunkt weitergeleitet wurde und
dass die neue Einhängung selbst eine Abhängige ist (von der Gemeinschaftsgruppe 4):
sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
168 167 8:23 / /mntX rw,relatime shared:1
169 167 8:22 / /mntY rw,relatime master:2
173 168 8:3 / /mntX/a rw,relatime shared:3
175 169 8:5 / /mntY/b rw,relatime
179 169 8:1 / /mntY/c rw,relatime master:4
MS_UNBINDABLE-Beispiel
Einer der Hauptzwecke der nicht-bindfähigen Einhängungen ist die Vermeidung des Problems
der »Einhängepunktexplosionen«, bei der wiederholt durchgeführte Einhängungen mit der
Option bind eines Unterbaums auf einer höheren Ebene in einem Einhängepunkt auf
niedrigeren Ebene ausgeführt werden. Das Problem wird in der nachfolgenden Shell-Sitzung
dargestellt.
Nehmen wir an, wir haben ein System mit folgenden Einhängepunkten:
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
Nehmen wir weiterhin an, dass wir das Wurzelverzeichnis rekursiv unter den
Home-Verzeichnissen verschiedener Benutzer mit der Option bind einhängen möchten. Wir
machen dies für den ersten Benutzer und untersuchen die Einhängepunkte:
# mount --rbind / /home/cecilia/
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
Wenn wir diese Aktion für den zweiten Benutzer wiederholen, beginnen wir, das
Explosionsproblem zu sehen:
# mount --rbind / /home/henry
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY
Unter /home/henry haben wir nicht nur die Einhängungen /mntX und /mntY rekursiv
hinzugefügt, sondern auch die rekursiven Einhängungen dieser Verzeichnisse unter
/home/cecilia, die im vorherigen Schritt erstellt wurden. Bei der Wiederholung dieses
Schrittes für einen dritten Benutzer wird es offensichtlich, dass die Explosion von
exponentieller Natur ist:
# mount --rbind / /home/otto
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/henry/home/cecilia
/dev/sdb6 on /home/henry/home/cecilia/mntX
/dev/sdb7 on /home/henry/home/cecilia/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY
/dev/sda1 on /home/otto/home/cecilia
/dev/sdb6 on /home/otto/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/cecilia/mntY
/dev/sda1 on /home/otto/home/henry
/dev/sdb6 on /home/otto/home/henry/mntX
/dev/sdb7 on /home/otto/home/henry/mntY
/dev/sda1 on /home/otto/home/henry/home/cecilia
/dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
/dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
Das Einhänge-Explosionsproblem im obigen Szenario kann vermieden werden, indem jede der
neuen Einhängungen nicht-bindfähig gemacht wird. Die Auswirkung ist, dass rekursive
Einhängungen des Wurzelverzeichnisses sich nicht bei nicht-bindfähigen Einhängungen
replizieren werden. Wir machen eine solche Einhängung für den ersten Benutzer:
# mount --rbind --make-unbindable / /home/cecilia
Bevor wir fortfahren, zeigen wir, dass die nicht-bindfähigen Einhängungen in der Tat nicht
bindfähig sind:
# mkdir /mntZ
# mount --bind /home/cecilia /mntZ
mount: wrong fs type, bad option, bad superblock on /home/cecilia,
missing codepage or helper program, or other error
In some cases useful info is found in syslog - try
dmesg | tail or so.
Jetzt erstellen wir nicht bindfähige rekursive Einhängungen mit der Option bind für die
anderen zwei Benutzer:
# mount --rbind --make-unbindable / /home/henry
# mount --rbind --make-unbindable / /home/otto
Bei der Untersuchung der Liste der Einhängepunkte sehen wir, dass es keine Explosion der
Einhängepunkte gab, da die nicht bindfähigen Einhängungen nicht unter den Verzeichnissen
der jeweiligen Benutzer repliziert wurden:
# mount | awk '{print $1, $2, $3}'
/dev/sda1 on /
/dev/sdb6 on /mntX
/dev/sdb7 on /mntY
/dev/sda1 on /home/cecilia
/dev/sdb6 on /home/cecilia/mntX
/dev/sdb7 on /home/cecilia/mntY
/dev/sda1 on /home/henry
/dev/sdb6 on /home/henry/mntX
/dev/sdb7 on /home/henry/mntY
/dev/sda1 on /home/otto
/dev/sdb6 on /home/otto/mntX
/dev/sdb7 on /home/otto/mntY
Weiterleitungstyp-Übergänge
Die nachfolgende Tabelle zeigt die Auswirkung, die die Anwendung eines neuen
Weiterleitungstyps (d.h. mount --make-xxxx) auf bestehende Weiterleitungstypen eines
Einhängepunktes hat. Die Zeilen entsprechen den bestehenden Weiterleitungstypen und die
Spalten sind die neuen Weiterleitungseinstellungen. Aus Platzgründen ist »private«
(privat) mit »priv« und »unbindable« (nicht bindfähig) mit »unbind« abgekürzt.
make-shared make-slave make-priv make-unbind
─────────────┬───────────────────────────────────────────────────────
shared │shared slave/priv [1] priv unbind
slave │slave+shared slave [2] priv unbind
slave+shared │slave+shared slave priv unbind
private │shared priv [2] priv unbind
unbindable │shared unbind [2] priv unbind
Beachten Sie die folgenden Details zu der Tabelle:
[1] Falls eine gemeinsame Einhängung die einzige in ihrer Gemeinschaftsgruppe ist, wird
sie als abhängige auch automatisch privat.
[2] Abhängig machen einer nicht gemeinsamen Einhängung hat keine Auswirkung auf die
Einhängung.
Semantik von Bind (MS_BIND)
Nehmen wir an, dass der folgende Befehl ausgeführt wird:
mount --bind A/a B/b
Hier ist A der Quelleinhängepunkt, B der Zieleinhängepunkt, a ist ein Unterverzeichnispfad
unter dem Einhängepunkt A und b ist ein Unterverzeichnispfad unter dem Einhängungspunkt B.
Der Weiterleitungstyp der resultierenden Einhängung B/b hängt von den Weiterleitungstypen
der Einhängepunkte A und B ab und wird in der folgenden Tabelle zusammengefasst.
Quelle(A)
shared private slave unbind
────────────────────────┬───────────────────────────────────────────
Ziel(B) shared │shared shared slave+shared ungültig
nicht gemeinsam│shared private slave ungültig
Beachten Sie, dass ein rekursives Bind eines Unterbaums der gleichen Semantik wie der
Bind-Aktion auf jede Einhängung im Unterbaum folgt. (Nicht-Bind-fähige Einhängungen werden
automatisch am Zieleinhängepunkt abgeschnitten.)
Für weitere Details siehe Documentation/filesystems/sharedsubtree.txt in dem
Kernelquellbaum.
Semantik von Move (MS_MOVE)
Nehmen wir an, dass der folgende Befehl ausgeführt wird:
mount --move A B/b
Hier ist A der Quelleinhängepunkt, B der Zieleinhängepunkt und b ist der
Unterverzeichnispfad unter dem Einhängepunkt B. Der Weiterleitungstyp der entstehenden
Einhängung B/b hängt von den Weiterleitungstypen der Einhängepunkte A und B ab und wird in
der nachfolgenden Tabelle zusammengefasst.
Quelle(A)
shared private slave unbind
────────────────────────┬─────────────────────────────────────────────
Ziel(B) shared │shared shared slave+shared ungültig
nicht gemeinsam│shared private slave unbindable
Hinweis: Das Verschieben einer Einhängung, die sich unter einer gemeinsamen Einhängung
befindet, ist ungültig.
Für weitere Details siehe Documentation/filesystems/sharedsubtree.txt in dem
Kernelquellbaum.
Einhänge-Semantik
Angenommen, wir verwenden folgenden Befehl, um einen Einhängepunkt zu erstellen:
mount Gerät B/b
Hier ist B der Zieleinhängepunkt und b der Unterverzeichnispfad unter dem Einhängepunkt B.
Der Weiterleitungstyp der entstehenden Einhängung B/b folgt den gleichen Regeln wie für
eine Einhängung mit der Option bind, bei der der Weiterleitungstyp der Quelleinhängung
immer als privat betrachtet wird.
Aushänge-Semantik
Angenommen, wir verwenden folgenden Befehl, um einen Einhängepunkt aufzulösen:
umount A
Hier ist A ein Einhängepunkt auf B/b, wobei B der Elterneinhängepunkt und b ein
Unterverzeichnispfad unterhalb des Einhängepunkts B ist. Falls B gemeinsam ist, dann
werden alle kürzlich eingehängten Einhängungen ausgehängt, die sich bei b befinden, die
Weiterleitungen von der Einhängung B erhalten und keine Untereinhängungen haben.
Die /proc/[PID]/mountinfo-Markierung propagate_from
Die Markierung propagate_from:X wird in den optionalen Feldern des Datensatzes
/proc/[PID]/mountinfo gezeigt, falls es einen Prozess gibt, der den Master der direkt
Abhängigen nicht sehen kann (d.h. der Pfadname vom Master ist von dem
Dateisystemwurzelverzeichnis aus nicht erreichbar) und so nicht die Weiterleitungskette
zwischen Einhängungen, die er sehen kann, bestimmen kann.
In dem folgenden Beispiel erstellen wir zuerst eine Kette aus zwei Gliedern zwischen
Master und Abhängiger, zwischen den Einhängungen /mnt, /tmp/etc und /mnt/tmp/etc. Dann
wird der Befehl chroot(1) verwandt, um den Einhängepunkt /tmp/etc vom Wurzelverzeichnis
unerreichbar zu bekommen und damit eine Situation zu erstellen, bei der der Master von
/mnt/tmp/etc nicht vom (neuen) Wurzelverzeichnis des Prozesses aus erreichbar ist.
Zuerst machen wir eine Einhängung mit der Option bind des Wurzelverzeichnisses auf /mnt
und dann eine Einhängung mit der Option bind von /proc bei /mnt/proc, so dass nach einem
späteren chroot(1) das Dateisystem proc(5) an dem korrekten Ort in der Umgebung innerhalb
des Chroots sichtbar bleibt.
# mkdir -p /mnt/proc
# mount --bind / /mnt
# mount --bind /proc /mnt/proc
Als nächstes stellen wir sicher, dass die Einhängung /mnt eine gemeinsame Einhängung in
der neuen Gemeinschaftsgruppe (ohne weitere Mitglieder) ist:
# mount --make-private /mnt # Von jeder vorherigen Gemeinschaftsgruppe isolieren
# mount --make-shared /mnt
# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
239 61 8:2 / /mnt … shared:102
248 239 0:4 / /mnt/proc … shared:5
Als nächstes hängen wir /mnt/etc auf /tmp/etc mit der Option bind ein:
# mkdir -p /tmp/etc
# mount --bind /mnt/etc /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt … shared:102
248 239 0:4 / /mnt/proc … shared:5
267 40 8:2 /etc /tmp/etc … shared:102
Anfänglich sind diese zwei Einhängepunkte in der gleichen Gemeinschaftsgruppe, aber dann
machen wir /tmp/etc eine Abhängige von /mnt/etc, und dann machen wir /tmp/etc auch
gemeinsam, so dass es Ereignisse an die nächste Abhängige in der Kette weiterleiten kann:
# mount --make-slave /tmp/etc
# mount --make-shared /tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt … shared:102
248 239 0:4 / /mnt/proc … shared:5
267 40 8:2 /etc /tmp/etc … shared:105 master:102
Dann hängen wir /tmp/etc auf /mnt/tmp/etc mit der Option bind ein. Wieder sind die zwei
Einhängepunkte anfänglich in der gleichen Gemeinschaftsgruppe, aber wir machen
/mnt/tmp/etc eine Abhängige von /tmp/etc:
# mkdir -p /mnt/tmp/etc
# mount --bind /tmp/etc /mnt/tmp/etc
# mount --make-slave /mnt/tmp/etc
# cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
239 61 8:2 / /mnt … shared:102
248 239 0:4 / /mnt/proc … shared:5
267 40 8:2 /etc /tmp/etc … shared:105 master:102
273 239 8:2 /etc /mnt/tmp/etc … master:105
In vorhergehender Ausgabe können wir sehen, dass /mnt der Master der Abhängigen /tmp/etc
ist, die wiederum der Master der Abhängigen /mnt/tmp/etc ist.
Dann wechseln wir mit chroot(1) zu dem Verzeichnis /mnt, wodurch die Einhängung mit der
Kennung 267 vom (neuen) Wurzelverzeichnis aus nicht mehr erreichbar ist:
# chroot /mnt
Wenn wir den Zustand der Einhängungen innerhalb der Chroot-Umgebung untersuchen, sehen wir
folgendes:
# cat /proc/self/mountinfo | sed 's/ - .*//'
239 61 8:2 / / … shared:102
248 239 0:4 / /proc … shared:5
273 239 8:2 /etc /tmp/etc … master:105 propagate_from:102
Oben sehen wir, dass die Einhängung mit der Kennung 273 eine Abhängige ist, deren Master
die Gemeinschaftsgruppe 105 ist. Der Einhängepunkt für diesen Master kann nicht erreicht
werden, und daher wird eine Markierung propagate_from angezeigt, die darauf aufmerksam
macht, dass die nahest-liegende dominante Gemeinschaftsgruppe (d.h. der nächste
erreichbare Einhängepunkt in der Abhängigkeitskette) die Gemeinschaftsgruppe mit der
Kennung 102 ist (die dem Einhängepunkt /mnt entspricht, bevor der chroot(1) durchgeführt
wurde.)
VERSIONEN
Einhängenamensräume erschienen erstmalig in Linux 2.4.19.
KONFORM ZU
Namensräume sind eine Linux-spezifische Funktionalität.
ANMERKUNGEN
Der einem neuen Einhängepunkt zugewiesene Weiterleitungstyp hängt vom Weiterleitungstyp
der Elterneinhängung ab. Falls der Einhängepunkt eine Elterneinhängung hat (d.h. der
Einhängungspunkt ist nicht die Wurzel) und der Weiterleitungstyp der Elterneinhängung
MS_SHARED ist, dann ist der Weiterleitungstyp der neuen Einhängung auch MS_SHARED.
Andernfalls ist der Einhängungstyp der neuen Einhängung MS_PRIVATE.
Unbenommen der Tatsache, dass der Standard-Weiterleitungstyp für neue Einhängepunkte in
vielen Fällen MS_PRIVATE ist, ist MS_SHARED normalerweise nützlicher. Aus diesem Grund
hängt systemd(1) beim Systemstart alle Einhängepunkte neu mit MS_SHARED ein. Daher ist auf
modernen Systemen der Standard-Weiterleitungstyp in der Praxis MS_SHARED.
Da bei der Verwendung von unshare(1) typischerweise das Ziel darin besteht, vollständige
Isolierung der Einhängepunkte in dem neuen Namensraum zu erreichen, kehrt unshare(1) (seit
util-linux Version 2.27) den durch systemd(1) durchgeführten Schritt um, indem es in dem
neuen Namensraum alle Einhängepunkte zu privaten macht. Das bedeutet, unshare(1) führt das
Äquivalent des folgenden Befehls im neuen Namensraum aus:
mount --make-rprivate /
Um dies zu verhindern, können Sie die Option --propagation unchanged für unshare(1)
verwenden.
Eine Anwendung, die einen neuen Einhängenamensraum direkt mit clone(2) oder unshare(2)
erzeugt, könnte den Wunsch haben, die Weiterleitung von Einhängeereignissen in andere
Einhängenamensräume zu verhindern (wie dies durch unshare(1) erfolgt). Dies kann durch
Änderung des Einhängetyps von Einhängepunkten in dem neuen Namensraum auf entweder
MS_SLAVE oder MS_PRIVATE erfolgen, indem ein Aufruf folgender Art erfolgt:
mount(NULL, "/", MS_SLAVE | MS_REC, NULL);
Für eine Diskussion von Weiterleitungstypen beim Verschieben von Einhängungen (MS_MOVE)
und der Erstellung von Einhängungen mit der Option bind (MS_BIND) siehe
Documentation/filesystems/sharedsubtree.txt.
BEISPIELE
Siehe pivot_root(2).
SIEHE AUCH
unshare(1), clone(2), mount(2), pivot_root(2), setns(2), umount(2), unshare(2), proc(5),
namespaces(7), user_namespaces(7), findmnt(8), mount(8), pivot_root(8), umount(8)
Documentation/filesystems/sharedsubtree.txt im Kernelquellbaum.
KOLOPHON
Diese Seite ist Teil der Veröffentlichung 5.10 des Projekts Linux-man-pages. Eine
Beschreibung des Projekts, Informationen, wie Fehler gemeldet werden können sowie die
aktuelle Version dieser Seite finden sich unter https://www.kernel.org/doc/man-pages/.
Ü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 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ 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⟩.