mount_namespaces(7) Miscellaneous Information Manual mount_namespaces(7) BEZEICHNUNG mount_namespaces - Uberblick uber Linux-Einhange-Namensraume BESCHREIBUNG Fur einen Uberblick uber Namensraume, siehe namespaces(7). Einhangenamensraume ermoglichen es, die Listen der von Prozessen in jeder Namensrauminstanz gesehenen Einhangungen voneinander zu isolieren. Daher wird jeder Prozess in jeder der Einhange-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 Einhangenamensraumen, in denen sich der Prozess mit der PID PID befindet. (Alle Prozesse, die sich in dem gleichen Einhangenamensraum befinden, werden die gleiche Ansicht auf diese Dateien sehen.) Ein neuer Einhangenamensraum wird entweder mittels clone(2) oder mittels unshare(2) mit dem Schalter CLONE_NEWNS erstellt. Wenn ein neuer Einhangenamensraum erstellt wird, wird seine Einhangeliste wie folgt initialisiert: o Falls der Namensraum mittels clone(2) erstellt wurde, ist die Einhangeliste des Nachfolgenamensraums eine Kopie der Einhangeliste des Namensraums des Elternprozesses. o Falls der Namensraum mittels unshare(2) erstellt wurde, ist die Einhangeliste des neuen Namensraums eine Kopie der Einhangeliste in dem vorherigen Namensraum des aufrufenden Prozesses. Nachfolgende Anderungen an der Einhangeliste (mount(2) und umount(2)) in jedem der Namensraume wird (standardmassig) die Einhangeliste, die in den anderen Namensraumen gesehen wird, nicht betreffen (lesen Sie allerdings auch die nachfolgende Diskussion von gemeinsamen Unterbaumen). GEMEINSAME UNTERBAUME Nachdem die Implementierung von Einhangenamensraumen abgeschlossen war, zeigte die Erfahrung, dass die bereitgestellte Isolierung in einigen Fallen zu weit ging. Um beispielsweise eine frisch geladene optische Platte in allen Einhangenamensraumen zur Verfugung zu stellen, war in jedem der Namensraume eine Einhangeaktion notwendig. Fur diesen und andere Anwendungsfalle wurde die Funktionalitat gemeinsamer Unterbaume in Linux 2.6.15 eingefuhrt. Diese Funktionalitat erlaubt die automatische, kontrollierte Weiterleitung von mount(2)- und umount(2)-Ereignissen zwischen Namensraumen (oder genauer, zwischen Einhangungen, die Mitglied einer Gemeinschaftsgruppe sind, die Ereignisse aneinander weiterleiten). Jede Einhangung wird (mittels mount(2)) markiert, dass sie eine der folgenden Weiterleitungstypen hat: MS_SHARED Diese Einhangung nutzt Ereignisse mit Mitgliedern der Gemeinschaftsgruppe gemeinsam. mount(2)- und umount(2)-Ereignisse direkt unterhalb dieser Einhangung werden zu den anderen Einhangungen, die Mitglied dieser Gemeinschaftsgruppe sind, weitergeleitet. Weiterleitung bedeutet hier, dass der gleiche mount(2) oder umount(2) unter allen diesen Einhangungen in der Gemeinschaftsgruppe automatisch erfolgen wird. Entsprechend werden mount(2)- und umount(2)-Ereignisse, die unter anderen Einhangungen der Gruppe stattfinden, zu dieser Einhangung weitergeleitet. MS_PRIVATE Diese Einhangung ist privat; sie ist in keiner Gemeinschaftsgruppe. mount(2)- und umount(2)-Ereignisse werden nicht aus dieser Einhangung heraus oder in sie hinein weitergeleitet. MS_SLAVE mount(2)- und umount(2)-Ereignisse werden in diese Einhangung von einer ubergeordneten (Master-) Gemeinschaftsgruppe weitergeleitet. mount(2)- und umount(2)-Ereignisse unterhalb dieser Einhangung werden nicht zu anderen Mitgliedern der Gruppe weitergeleitet. Beachten Sie, dass eine Einhangung eine Abhangige von einer anderen Gemeinschaftsgruppe sein kann und gleichzeitig ein Mitglied in einer zweiten Gemeinschaftsgruppe sein kann, an die und von der sie mount(2)- und umount(2)-Ereignisse sendet bzw. empfangt. (Genauer gesagt kann eine Gemeinschaftsgruppe eine Abhangige einer anderen Gemeinschaftsgruppe sein). MS_UNBINDABLE Dies ist wie eine private Einhangung und zusatzlich kann diese Einhangung nicht mit der Option bind erfolgen. Wird versucht, diese Einhangung mit der Option bind einzuhangen (mount(2) mit dem Schalter MS_BIND), dann schlagt dies fehl. Wenn eine rekursive Einhangung mit der Option bind (mount(2) mit den Schaltern MS_BIND und MS_REC) auf einem Verzeichnisunterbaum erfolgt, werden alle Einhangungen 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 fur eine Diskussion der Weiterleitungstypen, die einer neuen Einhangung zugeordnet sind. Der Weiterleitungstyp ist eine einhangungsbezogene Einstellung: einige Einhangungen konnten als gemeinsam gekennzeichnet sein (wobei jede gemeinsame Einhangung ein Mitglied einer unterschiedlichen Gemeinschaftsgruppe ist), wahrend andere privat (oder abhangig oder nicht-bind-fahig) sind. Beachten Sie, dass der Weiterleitungstyp einer Einhangung bestimmt, ob mount(2)- und umount(2) von Einhangungen direkt unter der Einhangung weitergeleitet werden. Daher betrifft der Einhangungstyp nicht die Weiterleitung von Ereignissen fur weiter unten liegende Einhangungen. Was passiert, wenn die Einhangung selbst ausgehangt wird, wird durch den Weiterleitungstyp bestimmt, der fur die ubergeordnete Einhangung wirksam ist. Mitglieder werden zu einer Gemeinschaftsgruppe hinzugefugt, wenn eine Einhangung als gemeinsam markiert ist und entweder: (a) die Einhangung wahrend der Erstellung eines neuen Einhangenamensraumes repliziert wird; oder (b) eine neue Einhangung mit der Option bind von dieser Einhangung erstellt wird. In beiden Fallen tritt die neue Einhangung der Gemeinschaftsgruppe bei, bei der die bestehende Einhangung bereits Mitglied ist. Eine neue Gemeinschaftsgruppe wird auch erstellt, wenn eine nachfolgende Einhangung unter einer bestehenden Einhangung, die als gemeinsam markiert ist, erstellt wird. In diesem Fall wird die nachfolgende Einhangung als gemeinsam markiert und die entstehende Gemeinschaftsgruppe besteht aus allen Einhangungen, die unterhalb der Mitglieder der ubergeordneten Einhangung repliziert werden. Eine Einhangung hort auf, Mitglied einer Gemeinschaftsgruppe zu sein, wenn die Einhangung entweder explizit ausgehangt wird oder wenn die Einhangung implizit ausgehangt wird, da der Einhangenamensraum entfernt wird (da er keinen Mitgliedsprozess mehr hat). Der Weiterleitungstyp der Einhangungen in einem Einhangenamensraum kann mittels der >>optionalen Felder<< in /proc/PID/mountinfo offengelegt werden. (Siehe proc(5) fur Details zu dieser Datei.) Die folgenden Markierungen konnen in den optionalen Feldern fur einen Datensatz in dieser Datei auftauchen: shared:X Diese Einhangung wird in der Gemeinschaftsgruppe X gemeinsam benutzt. Jede Gemeinschaftsgruppe hat eine eindeutige Kennung, die durch den Kernel automatisch erstellt wird. Alle Einhangungen in der gleichen Gemeinschaftsgruppe werden die gleiche Kennung zeigen. (Diese Kennungen werden beginnend mit dem Wert 1 zugewiesen und konnen wiederbenutzt werden, wenn eine Gemeinschaftsgruppe keine Mitglieder mehr hat.) master:X Diese Einhangung ist eine Abhangige der gemeinsamen Gemeinschaftsgruppe X. propagate_from:X (seit Linux 2.6.26) Diese Einhangung ist eine Abhangige und empfangt 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 Einhangung 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-fahige Einhangung. Falls keine der obigen Markierungen vorhanden ist, dann ist dies eine private Einhangung. Beispiel fur MS_SHARED und MS_PRIVATE Nehmen wir an, dass wir im Terminal des anfanglichen Einhangenamensraums eine Einhangung als gemeinsam und eine andere als privat markieren, und uns dann die Einhangungen 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 konnen wir sehen, dass /mntS eine gemeinsame Einhangung in der Gemeinschaftsgruppe 1 ist und dass /mntP keine optionalen Markierungen hat und damit anzeigt, dass es eine private EInhangung ist. Die ersten zwei Felder in jedem Datensatz in dieser Datei sind die eindeutige Kennung fur diese Einhangung und die Einhangungskennung der Elterneinhangung. Wir konnen diese Datei weiter untersuchen, um zu sehen, dass die Elterneinhangung von /mntS und /mntP das Wurzelverzeichnis / ist, das privat eingehangt 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 Einhangenamensraum, in dem wir eine zweite Shell ausfuhren und die Einhangungen 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 Einhangenamensraum erhielt eine Kopie der Einhangungen des anfanglichen Einhangenamensraumes. Diese neuen Einhangungen behalten die gleichen Weiterleitungstypen bei, haben aber eindeutige Einhangekennungen. (Die Option --propagation unchanged verhindert, dass unshare(1) alle Einhangungen als privat markiert, wenn ein neuer Einhangenamensraum erstellt wird, wie er es sonst standardmassig machen wurde.) In dem zweiten Terminal erstellen wir jetzt Untereinhangungen 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 Einhangung (die Einstellung wurde von der Elterneinhangung ubernommen) und /mntP/b als private Einhangung erstellt wurde. Wird zum ersten Terminal zuruckgekehrt und das Ergebnis untersucht, konnen wir sehen, dass die neue Einhangung, die unterhalb der gemeinsamen Einhangung /mntS erstellt wurde, an die Einhangungen in seiner Gemeinschaftsgruppe weitergeleitet wurde (im anfanglichen Einhangenamensraum), aber die Einhangung, die unter der privaten Einhangung /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 eine Einhangung eine Abhangige, ist es moglich, weitergeleitete mount(2)- und umount(2)-Ereignisse von einer gemeinsamen Master-Gemeinschaftsgruppe zu erhalten und zugleich sie daran zu hindern, Ereignisse zu diesem Master weiterzuleiten. Dies ist nutzlich, wenn Sie (beispielsweise) ein Einhangeereignis erhalten mochten, wenn eine optische Platte in der gemeinsamen Gemeinschaftsgruppe des Masters eingehangt wird (in einem anderen Einhangenamensraum), aber Sie verhindern mochten, dass mount(2)- und umount(2)-Ereignisse unter der Einhangung der Abhangigen zu Seiteneffekten in anderen Namensraumen fuhren. Wir zeigen die Auswirkung der Abhangigen, indem wir zuerst zwei Einhangungen als gemeinsam im anfanglichen 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 Einhangenamensraum und untersuchen die Einhangungen: 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 Einhangenamensraum konnen wir eine Einhangung als Abhangige 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 abhangige Einhangung ist, die Weiterleitungsereignisse von der gemeinsamen Gemeinschaftsgruppe mit der Kennung 2 erhalt. Im neuen Namensraum wird jetzt fortgefahren und Untereinhangungen 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 Einhangungen in den neuen Einhangenamensraumen untersuchen, sehen wir, dass /mntX/a als eine neue gemeinsame Einhangung erstellt wurde (die die Einstellung >>shared<< ihrer Elterneinhangung geerbt hat) und dass /mntY/b als eine private Einhangung 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 Zuruck im ersten Terminal (im anfanglichen Einhangenamensraum) sehen wir, dass die Einhangung /mntX/a zu dem Mitglied der Gemeinschaftsgruppe weitergeleitet wurde (der gemeinsame /mntX), aber dass die Einhangung /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 neue Einhangung 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 Einhangungen in dem zweiten Einhangenamensraum untersuchen, sehen wir, dass in diesem Fall die Einhangung zu der abhangigen Einhangung weitergeleitet wurde und dass die neue Einhangung selbst eine Abhangige 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-bindfahigen Einhangungen ist die Vermeidung des Problems der >>Einhangeexplosionen<<, bei der wiederholt durchgefuhrte Einhangungen mit der Option bind eines Unterbaums auf einer hoheren Ebene in einer Einhangung auf niedrigeren Ebene ausgefuhrt werden. Das Problem wird in der nachfolgenden Shell-Sitzung dargestellt. Nehmen wir an, wir haben ein System mit folgenden Einhangungen: # 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 einhangen mochten. Wir machen dies fur den ersten Benutzer und untersuchen die Einhangungen: # 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 fur 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 Einhangungen /mntX und /mntY rekursiv hinzugefugt, sondern auch die rekursiven Einhangungen dieser Verzeichnisse unter /home/cecilia, die im vorherigen Schritt erstellt wurden. Bei der Wiederholung dieses Schrittes fur 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 Einhange-Explosionsproblem im obigen Szenario kann vermieden werden, indem jede der neuen Einhangungen nicht-bindfahig gemacht wird. Die Auswirkung ist, dass rekursive Einhangungen des Wurzelverzeichnisses sich nicht bei nicht-bindfahigen Einhangungen replizieren werden. Wir machen eine solche Einhangung fur den ersten Benutzer: # mount --rbind --make-unbindable / /home/cecilia Bevor wir fortfahren, zeigen wir, dass die nicht-bindfahigen Einhangungen in der Tat nicht bindfahig 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 einigen Fallen konnnen in Syslog hilfreiche Informationen gefunden werden - versuchen Sie >>dmesg | tail<< oder so. Jetzt erstellen wir nicht bindfahige rekursive Einhangungen mit der Option bind fur die anderen zwei Benutzer: # mount --rbind --make-unbindable / /home/henry # mount --rbind --make-unbindable / /home/otto Bei der Untersuchung der Liste der Einhangungen sehen wir, dass es keine Explosion der Einhangungen gab, da die nicht bindfahigen Einhangungen 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-Ubergange Die nachfolgende Tabelle zeigt die Auswirkung, die die Anwendung eines neuen Weiterleitungstyps (d.h. mount --make-xxxx) auf bestehende Weiterleitungstypen einer Einhangung hat. Die Zeilen entsprechen den bestehenden Weiterleitungstypen und die Spalten sind die neuen Weiterleitungseinstellungen. Aus Platzgrunden ist >>private<< (privat) mit >>priv<< und >>unbindable<< (nicht bindfahig) mit >>unbind<< abgekurzt. |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 Einhangung die einzige in ihrer Gemeinschaftsgruppe ist, wird sie als abhangige auch automatisch privat. [2] Abhangig machen einer nicht gemeinsamen Einhangung hat keine Auswirkung auf die Einhangung. Semantik von Bind (MS_BIND) Nehmen wir an, dass der folgende Befehl ausgefuhrt wird: mount --bind A/a B/b Hier ist A die Quelleinhangung, B die Zieleinhangung, a ist ein Unterverzeichnispfad unter dem Einhangungspunkt A und b ist ein Unterverzeichnispfad unter dem Einhangungspunkt B. Der Weiterleitungstyp der resultierenden Einhangung B/b hangt von den Weiterleitungstypen der Einhangungen A und B ab und wird in der folgenden Tabelle zusammengefasst. Quelle(A) |shared private slave unbind ------------------------+--------------------------------------------- Ziel(B) shared |shared shared slave+shared ungultig nicht gemeinsam|shared private slave ungultig Beachten Sie, dass ein rekursives Bind eines Unterbaums der gleichen Semantik wie der Bind-Aktion auf jede Einhangung im Unterbaum folgt. (Nicht-Bind-fahige Einhangungen werden automatisch am Zieleinhangepunkt abgeschnitten.) Fur weitere Details siehe Documentation/filesystems/sharedsubtree.rst in dem Kernelquellbaum. Semantik von Move (MS_MOVE) Nehmen wir an, dass der folgende Befehl ausgefuhrt wird: mount --move A B/b Hier ist A die Quelleinhangung, B die Zieleinhangung und b ist der Unterverzeichnispfad unter dem Einhangepunkt B. Der Weiterleitungstyp der entstehenden Einhangung B/b hangt von den Weiterleitungstypen der Einhangungen A und B ab und wird in der nachfolgenden Tabelle zusammengefasst. Quelle(A) |shared private slave unbind ------------------------+--------------------------------------------- Ziel(B) shared |shared shared slave+shared ungultig nicht gemeinsam|shared private slave unbindable Hinweis: Das Verschieben einer Einhangung, die sich unter einer gemeinsamen Einhangung befindet, ist ungultig. Fur weitere Details siehe Documentation/filesystems/sharedsubtree.rst in dem Kernelquellbaum. Einhange-Semantik Angenommen, wir verwenden folgenden Befehl, um eine Einhangung zu erstellen: mount Gerat B/b Hier ist B die Zieleinhangung und b der Unterverzeichnispfad unter dem Einhangepunkt B. Der Weiterleitungstyp der entstehenden Einhangung B/b folgt den gleichen Regeln wie fur eine Einhangung mit der Option bind, bei der der Weiterleitungstyp der Quelleinhangung immer als privat betrachtet wird. Aushange-Semantik Angenommen, wir verwenden folgenden Befehl, um eine Einhangung aufzulosen: umount A Hier ist A eine Einhangung auf B/b, wobei B die Elterneinhangung und b ein Unterverzeichnispfad unterhalb des Einhangepunkts B ist. Falls B gemeinsam ist, dann werden alle kurzlich eingehangten Einhangungen ausgehangt, die sich bei b befinden, die Weiterleitungen von der Einhangung B erhalten und keine Untereinhangungen 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 Abhangigen nicht sehen kann (d.h. der Pfadname vom Master ist von dem Dateisystemwurzelverzeichnis aus nicht erreichbar) und so nicht die Weiterleitungskette zwischen Einhangungen, die er sehen kann, bestimmen kann. In dem folgenden Beispiel erstellen wir zuerst eine Kette aus zwei Gliedern zwischen Master und Abhangiger, zwischen den Einhangungen /mnt, /tmp/etc und /mnt/tmp/etc. Dann wird der Befehl chroot(1) verwandt, um den Einhangepunkt /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 Einhangung mit der Option bind des Wurzelverzeichnisses auf /mnt und dann eine Einhangung mit der Option bind von /proc bei /mnt/proc, so dass nach einem spateren 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 nachstes stellen wir sicher, dass die Einhangung /mnt eine gemeinsame Einhangung 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 nachstes hangen 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 Anfanglich sind diese zwei Einhangungen in der gleichen Gemeinschaftsgruppe, aber dann machen wir /tmp/etc eine Abhangige von /mnt/etc, und dann machen wir /tmp/etc auch gemeinsam, so dass es Ereignisse an die nachste Abhangige 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 hangen wir /tmp/etc auf /mnt/tmp/etc mit der Option bind ein. Wieder sind die zwei Einhangungen anfanglich in der gleichen Gemeinschaftsgruppe, aber wir machen /mnt/tmp/etc eine Abhangige 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 konnen wir sehen, dass /mnt der Master der Abhangigen /tmp/etc ist, die wiederum der Master der Abhangigen /mnt/tmp/etc ist. Dann wechseln wir mit chroot(1) zu dem Verzeichnis /mnt, wodurch die Einhangung mit der Kennung 267 vom (neuen) Wurzelverzeichnis aus nicht mehr erreichbar ist: # chroot /mnt Wenn wir den Zustand der Einhangungen 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 Einhangung mit der Kennung 273 eine Abhangige ist, deren Master die Gemeinschaftsgruppe 105 ist. Der Einhangepunkt fur 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 nachste erreichbare Einhangepunkt in der Abhangigkeitskette) die Gemeinschaftsgruppe mit der Kennung 102 ist (die dem Einhangepunkt /mnt entspricht, bevor der chroot(1) durchgefuhrt wurde.) STANDARDS Linux. GESCHICHTE Linux 2.4.19. ANMERKUNGEN Der einer neuen Einhangung zugewiesene Weiterleitungstyp hangt vom Weiterleitungstyp der Elterneinhangung ab. Falls die Einhangung eine Elterneinhangung hat (d.h. der Einhangungspunkt ist nicht die Wurzel) und der Weiterleitungstyp der Elterneinhangung MS_SHARED ist, dann ist der Weiterleitungstyp der neuen Einhangung auch MS_SHARED. Andernfalls ist der Einhangungstyp der neuen Einhangung MS_PRIVATE. Unbenommen der Tatsache, dass der Standard-Weiterleitungstyp fur neue Einhangungen in vielen Fallen MS_PRIVATE ist, ist MS_SHARED normalerweise nutzlicher. Aus diesem Grund hangt systemd(1) beim Systemstart alle Einhangungen 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, vollstandige Isolierung der Einhangungen in dem neuen Namensraum zu erreichen, kehrt unshare(1) (seit util-linux 2.27) den durch systemd(1) durchgefuhrten Schritt um, indem es in dem neuen Namensraum alle Einhangungen zu privaten macht. Das bedeutet, unshare(1) fuhrt das Aquivalent des folgenden Befehls im neuen Namensraum aus: mount --make-rprivate / Um dies zu verhindern, konnen Sie die Option --propagation unchanged fur unshare(1) verwenden. Eine Anwendung, die einen neuen Einhangenamensraum direkt mit clone(2) oder unshare(2) erzeugt, konnte den Wunsch haben, die Weiterleitung von Einhangeereignissen in andere Einhangenamensraume zu verhindern (wie dies durch unshare(1) erfolgt). Dies kann durch Anderung des Einhangetyps von Einhangungen 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); Fur eine Diskussion von Weiterleitungstypen beim Verschieben von Einhangungen (MS_MOVE) und der Erstellung von Einhangungen mit der Option bind (MS_BIND) siehe Documentation/filesystems/sharedsubtree.rst. Beschrankungen fur Einhangenamensraume Beachten Sie die folgenden Punkte in Hinblick auf Einhangenamensraume: [1] Jeder Einhangenamensraum hat einen Eigentumer-Benutzernamensraum. Wie oben beschrieben wird beim Erstellen eines neuen Einhangenamensraumes seine Einhangeliste als Kopie der Einhangeliste eines anderen Einhangenamensraums initialisiert. Falls der neue Namensraum und der Namensraum, von dem die Einhangeliste kopiert wurde, verschiedenen Benutzernamensraumen gehoren, dann wird der neue Einhangenamensraum als weniger privilegiert betrachtet. [2] Beim Erstellen eines weniger privilegierten Einhangenamensraums werden gemeinsame Einhangungen zu abhangigen Einhangungen reduziert. Dies stellt sicher, dass Abbildungen, die in weniger privilegierten Namensraumen erfolgen, nicht in mehr privilegierte Namensraume weitergeleitet werden. [3] Einhangungen, die als gemeinsame Einheit von einem mehr privilegierten Einhangenamensraum kommen, werden zusammengeklemmt und konnen in einem weniger privilegierten Namensraum nicht getrennt werden. (Die Aktion unshare(2) CLONE_NEWNS bringt alle Einhangungen von dem ursprunglichen Einhangenamensraum als gemeinsame Einheit heruber und rekursive Einhangungen, die zwischen Einhangenamensraumen weiterleiten, werden als gemeinsame Einheit weitergeleitet.) In diesem Kontext bedeutet >>konnen nicht getrennt werden<<, dass die Einhangungen zusammengeklemmt sind, so dass sie nicht einzeln ausgehangt werden konnen. Betrachten Sie folgendes Beispiel: $ sudo sh # mount --bind /dev/null /etc/shadow # cat /etc/shadow # Ergibt keine Ausgabe Die obigen Schritte, die in einem mehr privilegierten Einhangenamensraum ausgefuhrt werden, haben eine Einhangung mit der Option bind erstellt, die die Inhalte der Schatten-Passwortdatei /etc/shadow verdeckt. Aus Sicherheitsgrunden sollte es nicht moglich sein, einen umount(2) dieser Einhangungen in einem weniger privilegierten Einhangenamensraum durchzufuhren, da dies den Inhalt von /etc/shadow offenlegen wurde. Nehmen wir an, dass wir einen Einhangenamensraum erstellen, der einem neuen Benutzernamensraum gehort. Der neue Einhangenamensraum wird Kopien aller Einhangungen von dem vorherigen Einhangenamensraum erben. Allerdings werden diese Einhangungen zusammengeklemmt werden, da der neue Einhangenamensraum weniger privilegiert ist. Konsequenterweise wird ein Versuch, einen umount(2) der Einhangung durchzufuhren, fehlschlagen, wie dies im folgenden Schritt zu sehen ist: # unshare --user --map-root-user --mount \ strace -o /tmp/log \ umount /mnt/dir umount: /etc/shadow: nicht eingehangt. # grep '^umount' /tmp/log umount2("/etc/shadow", 0) = -1 EINVAL (Invalid argument) Die Fehlermeldung von mount(8) irritiert etwas, aber die Ausgabe von strace(1) verrat, dass der zugrundeliegende Systemaufruf umount2(2) mit dem Fehler EINVAL fehlschlug. Der Kernel liefert diesen Fehler, um anzuzeigen, dass die Einhangung geklemmt ist. Beachten Sie allerdings, dass eine Einhangung oben auf eine geerbte geklemmte Einhangung in einem weniger privilegierten Einhangenamensraum aufgesetzt oder von dort wieder entfernt werden kann: # echo 'aaaaa' > /tmp/a # Datei, die auf /etc/shadow eingehangt werden soll # unshare --user --map-root-user --mount \ sh -c 'mount --bind /tmp/a /etc/shadow; cat /etc/shadow' aaaaa # umount /etc/shadow Der abschliessende Befehl umount(8) oben, der im anfanglichen Einhangenamensraum durchgefuhrt wird, macht die ursprungliche Datei /etc/shadow wieder in diesem Namensraum sichtbar. [4] Beachten Sie anschliessend an Schritt [3], dass es moglich ist, einen umount(2) auf einen gesamten Unterbaum von Einhangungen, der als Einheit in einen weniger privilegierten Einhangenamensraum weitergeleitet wurde, durchzufuhren. Das wird im nachfolgenden Beispiel dargestellt. Zuerst erstellen wir mittels unshare(1) einen neuen Benutzer- und Einhangenamensraum. In dem neuen Einhangenamensraum wird der Weiterleitungstyp aller Einhangungen auf privat gesetzt. Wir erstellen dann eine gemeinsame Einhangung mit der Option bind von /mnt und eine kleine Hierarchie von Einhangungen unterhalb dieser Einhangung. $ PS1='ns1# ' sudo unshare --user --map-root-user \ --mount --propagation private bash ns1# echo $$ # Wir benotigen die PID dieser Shell spater 778501 ns1# mount --make-shared --bind /mnt /mnt ns1# mkdir /mnt/x ns1# mount --make-private -t tmpfs none /mnt/x ns1# mkdir /mnt/x/y ns1# mount --make-private -t tmpfs none /mnt/x/y ns1# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 986 83 8:5 /mnt /mnt rw,relatime shared:344 989 986 0:56 / /mnt/x rw,relatime 990 989 0:57 / /mnt/x/y rw,relatime In der gleichen Shell-Sitzung fahren wir fort und erstellen eine zweite Shell in einem neuen Benutzernamensraum und einen (weniger privilegierten) Einhangenamensraum und prufen den Zustand der weitergeleiteten Einhangungen, deren Wurzel bei /mnt liegt. ns1# PS1='ns2# ' unshare --user --map-root-user \ --mount --propagation unchanged bash ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime Bemerkenswert in der obigen Ausgabe ist, dass der Weiterleitungstyp der Einhangung /mnt zu einer Abhangigen reduziert wurde, wie in Schritt [2] erlautert. Das bedeutet, dass Untereinhangungsereignisse vom Master in >>ns1<< weitergeleitet werden, aber Weiterleitungen nicht in die umgekehrte Richtung erfolgen werden. In einem anderen Terminalfenster verwenden wir nsenter(1), um den Einhangungs- und Benutzernamensraum zu betreten, der >>ns1<< entspricht. In diesem Terminalfenster hangen wir mit der Option bind rekursiv /mnt/x am Ort /mnt/ppp ein. $ PS1='ns3# ' sudo nsenter -t 778501 --user --mount ns3# mount --rbind --make-private /mnt/x /mnt/ppp ns3# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 986 83 8:5 /mnt /mnt rw,relatime shared:344 989 986 0:56 / /mnt/x rw,relatime 990 989 0:57 / /mnt/x/y rw,relatime 1242 986 0:56 / /mnt/ppp rw,relatime 1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518 Da der Weiterleitungstyp der Elterneinhangung /mnt gemeinsam war, leitete die rekursive Einhangung mit der Option bind einen kleinen Unterbaum von Einhangungen unter der abhangigen Einhangung /mnt nach >>ns2<< weiter. Dies kann durch Ausfuhren der folgenden Befehle in dieser Shell-Sitzung bestatigt werden: ns2# grep /mnt /proc/self/mountinfo | sed 's/ - .*//' 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime 1244 1239 0:56 / /mnt/ppp rw,relatime 1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518 Es ist zwar nicht moglich, einen umount(2) auf einen Teil des weitergeleiteten Unterbaums (/mnt/ppp/y) in >>ns2<< durchzufuhren, aber es ist moglich, einen umount(2) auf den gesamten Unterbaum durchzufuhren. Dies wird durch die folgenden Befehle gezeigt: ns2# umount /mnt/ppp/y umount: /mnt/ppp/y: nicht eingehangt. ns2# umount -l /mnt/ppp | sed 's/ - .*//' # Erfolgreich ns2# grep /mnt /proc/self/mountinfo 1239 1204 8:5 /mnt /mnt rw,relatime master:344 1240 1239 0:56 / /mnt/x rw,relatime 1241 1240 0:57 / /mnt/x/y rw,relatime [5] 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 Einhangenamensraum weitergeleitet werden und durfen in dem weniger privilegierten Namensraum nicht geandert werden. Dieser Punkt wird im nachfolgenden Beispiel verdeutlicht. Hier erstellen wir in einem mehr privilegierten Einhangenamensraum eine Einhangung mit der Option bind, die als nur-lesbar markiert ist. Aus Sicherheitsgrunden sollte es nicht moglich sein, die Einhangung in einem weniger privilegierten Einhangenamensraum schreibbar zu machen und tatsachlich verhindert der Kernel das: $ sudo mkdir /mnt/dir $ sudo mount --bind -o ro /some/path /mnt/dir $ sudo unshare --user --map-root-user --mount \ mount -o remount,rw /mnt/dir mount: /mnt/dir: Zugriff verweigert. [6] Eine Datei oder ein Verzeichnis, das ein Einhangepunkt in einem Namensraum ist, der kein Einhangepunkt in einem anderen Namensraum ist, kann umbenannt, mit der Funktion >>unlink<< geloscht oder in dem Einhangenamensraum, in dem er kein Einhangepunkt ist, geloscht (rmdir(2)) werden (abhangig von den normalen Berechtigungsprufungen). Konsequenterweise wird der Einhangepunkt in dem Einhangenamensraum, in dem er ein Einhangepunkt war, entfernt. Fruher (vor Linux 3.18) fuhrte der Versuch, eine Datei oder ein Verzeichnis, das ein Einhangepunkt in einem anderen Namensraum war, mit >>unlink<< zu loschen, umzubenennen oder zu entfernen zu dem Fehler EBUSY. Dieses Verhalten hatte technische Probleme bei der Durchsetzung (z.B. fur NFS) und ermoglichte Diensteverweigerungsangriffe gegen mehr privilegierte Benutzer (d.h. Verhinderung der Aktualisierung einzelner Dateien durch Einhangungen mit der Option bind daruber). BEISPIELE Siehe pivot_root(2). SIEHE AUCH unshare(1), clone(2), mount(2), mount_setattr(2), pivot_root(2), setns(2), umount(2), unshare(2), proc(5), namespaces(7), user_namespaces(7), findmnt(8), mount(8), pam_namespace(8), pivot_root(8), umount(8) Documentation/filesystems/sharedsubtree.rst im Kernelquellbaum. 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.06 31. Oktober 2023 mount_namespaces(7)