.\" -*- coding: UTF-8 -*- .\" Copyright (c) 2016, 2019 by Michael Kerrisk .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH MOUNT_NAMESPACES 7 "1. November 2020" Linux Linux\-Programmierhandbuch .SH BEZEICHNUNG mount_namespaces \- Überblick über Linux\-Einhänge\-Namensräume .SH BESCHREIBUNG Für einen Überblick über Namensräume, siehe \fBnamespaces\fP(7). .PP 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. .PP Die von den Dateien \fI/proc/[PID]/mounts\fP, \fI/proc/[PID]/mountinfo\fP und \fI/proc/[PID]/mountstats\fP (alle In \fBproc\fP(5) beschrieben) bereitgestellten Ansichten entsprechen den Einhängenamensräumen, in denen sich der Prozess mit der PID \fI[PID]\fP befindet. (Alle Prozesse, die sich in dem gleichen Einhängenamensraum befinden, werden die gleiche Ansicht auf diese Dateien sehen.) .PP Ein neuer Einhängenamensraum wird entweder mittels \fBclone\fP(2) oder mittels \fBunshare\fP(2) mit dem Schalter \fBCLONE_NEWNS\fP erstellt. Wenn ein neuer Einhängenamensraum erstellt wird, wird seine Einhängepunktliste wie folgt initialisiert: .IP * 3 Falls der Namensraum mittels \fBclone\fP(2) erstellt wurde, ist die Einhängepunktliste des Nachfolgenamensraums eine Kopie der Einhängepunktliste des Vorgängernamensraums. .IP * Falls der Namensraum mittels \fBunshare\fP(2) erstellt wurde, ist die Einhängepunktliste des neuen Namensraums eine Kopie der Einhängepunktliste in dem vorherigen Namensraum des aufrufenden Prozesses. .PP .\" .\" ============================================================ .\" Nachfolgende Änderungen an der Einhängepunktliste (\fBmount\fP(2) und \fBumount\fP(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). .SS "Beschränkungen für Einhängenamensräume" Beachten Sie die folgenden Punkte in Hinblick auf Einhängenamensräume: .IP * 3 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 \fIweniger privilegiert\fP betrachtet. .IP * 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. .IP * 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 \fBunshare\fP(2) \fBCLONE_NEWNS\fP 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.) .IP * .\" commit 9566d6742852c527bf5af38af5cbb878dad75705 .\" Author: Eric W. Biederman .\" Date: Mon Jul 28 17:26:07 2014 -0700 .\" .\" mnt: Correct permission checks in do_remount .\" Die Schalter \fBMS_RDONLY\fP, \fBMS_NOSUID\fP, \fBMS_NOEXEC\fP von \fBmount\fP(2) und die »atime«\-Schalter\-Einstellungen (\fBMS_NOATIME\fP, \fBMS_NODIRATIME\fP, \fBMS_RELATIME\fP) 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. .IP * .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree)) 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 (\fBrmdir\fP(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. .IP .\" mtk: The change was in Linux 3.18, I think, with this commit: .\" commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe .\" Author: Eric W. Biederman .\" Date: Tue Oct 1 18:33:48 2013 -0700 .\" .\" vfs: Lazily remove mounts on unlinked files and directories. .\" 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 \fBEBUSY\fP. Dieses Verhalten hatte technische Probleme bei der Durchsetzung (z.B. für NFS) und ermöglichte Diensteverweigerungsangriffe gegen mehr privilegierte Benutzer (d.h. Verhinderung der Aktualisierung einzelner Dateien durch Einhängungen mit der Option bind darüber). .SH "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\-\fIEreignissen\fP zwischen Namensräumen (oder, genauer, zwischen Mitgliedern einer \fIGemeinschaftsgruppe\fP, die Ereignisse aneinander weiterleiten). .PP Jeder Einhängepunkt wird (über \fBmount\fP(2)) markiert, dass er einen der folgenden \fIWeiterleitungstypen\fP hat: .TP \fBMS_SHARED\fP 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. \fIWeiterleitung\fP 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ängeereignisse, die unter anderen Einhängepunkten der Gruppe stattfinden, zu diesem Einhängepunkt weitergeleitet. .TP \fBMS_PRIVATE\fP Dieser Einhängepunkt ist privat; er ist in keiner Gemeinschaftsgruppe. Ein\- und Aushängeereignisse werden nicht aus diesem Einhängepunkt heraus oder in ihn hinein weitergeleitet. .TP \fBMS_SLAVE\fP 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. .IP 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). .TP \fBMS_UNBINDABLE\fP 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 (\fBmount\fP(2) mit dem Schalter \fBMS_BIND\fP), dann schlägt dies fehl. .IP Wenn eine rekursive Einhängung mit der Option bind (\fBmount\fP(2) mit den Schaltern \fBMS_BIND\fP und \fBMS_REC\fP) 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. .PP Bitte lesen Sie die HINWEISE für eine Diskussion der Weiterleitungstypen, die einer neuen Einhängung zugeordnet sind. .PP 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. .PP Beachten Sie, dass der Weiterleitungstyp einer Einhängung bestimmt, ob Ein\- und Aushängungen \fIdirekt unter\fP 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 \fIübergeordneten\fP Einhängepunkt wirksam ist. .PP Mitglieder werden zu einer \fIGemeinschaftsgruppe\fP hinzugefügt, wenn ein Einhängepunkt als gemeinsam markiert ist und entweder: .IP * 3 der Einhängepunkt während der Erstellung eines neuen Einhängenamensraumes repliziert wird; oder .IP * eine neue Einhängung mit der Option bind von diesem Einhängepunkt erstellt wird. .PP In beiden Fällen tritt der neue Einhängepunkt der Gemeinschaftsgruppe bei, bei der der bestehende Einhängepunkt bereits Mitglied ist. .PP 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. .PP 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). .PP Der Weiterleitungstyp des Einhängepunktes in einem Einhängenamensraum kann mittels der »optionalen Felder« in \fI/proc/[PID]/mountinfo\fP offengelegt werden. (Siehe \fBproc\fP(5) für Details zu dieser Datei.) Die folgenden Markierungen können in den optionalen Feldern für einen Datensatz in dieser Datei auftauchen: .TP \fIshared:X\fP Dieser Einhängepunkt wird in der Gemeinschaftsgruppe \fIX\fP 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.) .TP \fImaster:X\fP Diese Einhängung ist eine Abhängige der gemeinsamen Gemeinschaftsgruppe \fIX\fP. .TP \fIpropagate_from:X\fP (seit Linux 2.6.26) .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e Diese Einhängung ist eine Abhängige und empfängt Weiterleitungen von der gemeinsamen Gemeinschaftsgruppe \fIX\fP. Diese Markierung wird immer zusammen mit einer Markierung \fImaster:X\fP auftauchen. Hier ist \fIX\fP die naheliegendste dominante Gemeinschaftsgruppe unter dem Wurzelverzeichnis des Prozesses. Falls \fIX\fP der direkte Master der Einhängung ist oder falls es keine dominante Gemeinschaftsgruppe unterhalb der gleichen Wurzel gibt, dann ist nur das Feld \fImaster:X\fP und nicht das Feld \fIpropagate_from:X\fP vorhanden. Weitere Details folgen weiter unten. .TP \fIunbindable\fP Dies ist eine nicht\-bind\-fähige Einhängung. .PP Falls keine der obigen Markierungen vorhanden ist, dann ist dies eine private Einhängung. .SS "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 \fI/proc/self/mountinfo\fP anschauen: .PP .in +4n .EX sh1# \fBmount \-\-make\-shared /mntS\fP sh1# \fBmount \-\-make\-private /mntP\fP sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 77 61 8:17 / /mntS rw,relatime shared:1 83 61 8:15 / /mntP rw,relatime .EE .in .PP In der Ausgabe in \fI/proc/self/mountinfo\fP können wir sehen, dass \fI/mntS\fP eine gemeinsame Einhängung in der Gemeinschaftsgruppe 1 ist und dass \fI/mntP\fP 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 \fI/mntS\fP und \fI/mntP\fP das Wurzelverzeichnis \fI/\fP ist, das privat eingehängt wurde: .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | awk \(aq$1 == 61\(aq | sed \(aqs/ \- .*//\(aq\fP 61 0 8:2 / / rw,relatime .EE .in .PP In einem zweiten Terminal erstellen wir einen neuen Einhängenamensraum, in dem wir eine zweite Shell ausführen und die Einhängungen untersuchen: .PP .in +4n .EX $ \fBPS1=\(aqsh2# \(aq sudo unshare \-m \-\-propagation unchanged sh\fP sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 222 145 8:17 / /mntS rw,relatime shared:1 225 145 8:15 / /mntP rw,relatime .EE .in .PP .\" Since util-linux 2.27 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 \fI\-\-propagation\ unchanged\fP verhindert, dass \fBunshare\fP(1) alle Einhängungen als privat markiert, wenn ein neuer Einhängenamensraum erstellt wird, wie er es sonst standardmäßig machen würde.) .PP In dem zweiten Terminal erstellen wir jetzt Untereinhängungen unter sowohl \fI/mntS\fP als auch \fI/mntP\fP und untersuchen das Ergebnis: .PP .in +4n .EX sh2# \fBmkdir /mntS/a\fP sh2# \fBmount /dev/sdb6 /mntS/a\fP sh2# \fBmkdir /mntP/b\fP sh2# \fBmount /dev/sdb7 /mntP/b\fP sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP In obiger Ausgabe kann erkannt werden, dass \fI/mntS/a\fP als gemeinsame Einhängung (die Einstellung wurde von der Elterneinhängung übernommen) und \fI/mntP/b\fP als private Einhängung erstellt wurde. .PP 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 \fI/mntS\fP 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 \fI/mntP\fP erstellt wurde, nicht weitergeleitet wurde: .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .\" .SS 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. .PP Wir zeigen die Auswirkung der Abhängigen, indem wir zuerst zwei Einhängepunkte als gemeinsam im anfänglichen Namensraum markieren: .PP .in +4n .EX sh1# \fBmount \-\-make\-shared /mntX\fP sh1# \fBmount \-\-make\-shared /mntY\fP sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 132 83 8:23 / /mntX rw,relatime shared:1 133 83 8:22 / /mntY rw,relatime shared:2 .EE .in .PP Auf einem zweiten Terminal erstellen wir einen neuen Einhängenamensraum und untersuchen die Einhängepunkte: .PP .in +4n .EX sh2# \fBunshare \-m \-\-propagation unchanged sh\fP sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime shared:2 .EE .in .PP In dem neuen Einhängenamensraum können wir einen Einhängepunkt als Abhängigen markieren: .PP .in +4n .EX sh2# \fBmount \-\-make\-slave /mntY\fP sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 168 167 8:23 / /mntX rw,relatime shared:1 169 167 8:22 / /mntY rw,relatime master:2 .EE .in .PP Aus der obigen Ausgabe kann gesehen werden, dass \fI/mntY\fP jetzt eine abhängige Einhängung ist, die Weiterleitungsereignisse von der gemeinsamen Gemeinschaftsgruppe mit der Kennung 2 erhält. .PP Im neuen Namensraum wird jetzt fortgefahren und Untereinhängungen unter sowohl \fI/mntX\fP als auch \fI/mntY\fP erstellt: .PP .in +4n .EX sh2# \fBmkdir /mntX/a\fP sh2# \fBmount /dev/sda3 /mntX/a\fP sh2# \fBmkdir /mntY/b\fP sh2# \fBmount /dev/sda5 /mntY/b\fP .EE .in .PP Wenn wir den Zustand der Einhängepunkte in den neuen Einhängenamensräumen untersuchen, sehen wir, dass \fI/mntX/a\fP als eine neue gemeinsame Einhängung erstellt wurde (die die Einstellung »shared« ihrer Elterneinhängung geerbt hat) und dass \fI/mntY/b\fP als eine private Einhängung erstellt wurde: .PP .in +4n .EX sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP Zurück im ersten Terminal (im anfänglichen Einhängenamensraum) sehen wir, dass die Einhängung \fI/mntX/a\fP zu dem Mitglied der Gemeinschaftsgruppe weitergeleitet wurde (der gemeinsame \fI/mntX\fP), aber dass die Einhängung \fI/mntY/b\fP nicht weitergeleitet wurde: .PP .in +4n .EX sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP Jetzt erstellen wir eine neuen Einhängepunkt unter \fI/mntY\fP in der ersten Shell: .PP .in +4n .EX sh1# \fBmkdir /mntY/c\fP sh1# \fBmount /dev/sda1 /mntY/c\fP sh1# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP 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): .PP .in +4n .EX sh2# \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .\" .SS 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. .PP Nehmen wir an, wir haben ein System mit folgenden Einhängepunkten: .PP .in +4n .EX # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP /dev/sda1 on / /dev/sdb6 on /mntX /dev/sdb7 on /mntY .EE .in .PP 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: .PP .in +4n .EX # \fBmount \-\-rbind / /home/cecilia/\fP # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP /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 .EE .in .PP Wenn wir diese Aktion für den zweiten Benutzer wiederholen, beginnen wir, das Explosionsproblem zu sehen: .PP .in +4n .EX # \fBmount \-\-rbind / /home/henry\fP # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP /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 .EE .in .PP Unter \fI/home/henry\fP haben wir nicht nur die Einhängungen \fI/mntX\fP und \fI/mntY\fP rekursiv hinzugefügt, sondern auch die rekursiven Einhängungen dieser Verzeichnisse unter \fI/home/cecilia\fP, 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: .PP .in +4n .EX # \fBmount \-\-rbind / /home/otto\fP # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP /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 .EE .in .PP 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: .PP .in +4n .EX # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP .EE .in .PP Bevor wir fortfahren, zeigen wir, dass die nicht\-bindfähigen Einhängungen in der Tat nicht bindfähig sind: .PP .in +4n .EX # \fBmkdir /mntZ\fP # \fBmount \-\-bind /home/cecilia /mntZ\fP 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. .EE .in .PP Jetzt erstellen wir nicht bindfähige rekursive Einhängungen mit der Option bind für die anderen zwei Benutzer: .PP .in +4n .EX # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP .EE .in .PP 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: .PP .in +4n .EX # \fBmount | awk \(aq{print $1, $2, $3}\(aq\fP /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 .EE .in .\" .SS Weiterleitungstyp\-Übergänge Die nachfolgende Tabelle zeigt die Auswirkung, die die Anwendung eines neuen Weiterleitungstyps (d.h. \fImount \-\-make\-xxxx\fP) 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. .TS lb2 lb2 lb2 lb2 lb1 lb | l l l l l. 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 .TE .sp 1 Beachten Sie die folgenden Details zu der Tabelle: .IP [1] 4 Falls eine gemeinsame Einhängung die einzige in ihrer Gemeinschaftsgruppe ist, wird sie als abhängige auch automatisch privat. .IP [2] .\" Abhängig machen einer nicht gemeinsamen Einhängung hat keine Auswirkung auf die Einhängung. .SS "Semantik von Bind (MS_BIND)" Nehmen wir an, dass der folgende Befehl ausgeführt wird: .PP .in +4n .EX mount \-\-bind A/a B/b .EE .in .PP Hier ist \fIA\fP der Quelleinhängepunkt, \fIB\fP der Zieleinhängepunkt, \fIa\fP ist ein Unterverzeichnispfad unter dem Einhängepunkt \fIA\fP und \fIb\fP ist ein Unterverzeichnispfad unter dem Einhängungspunkt \fIB\fP. Der Weiterleitungstyp der resultierenden Einhängung \fIB/b\fP hängt von den Weiterleitungstypen der Einhängepunkte \fIA\fP und \fIB\fP ab und wird in der folgenden Tabelle zusammengefasst. .PP .TS lb2 lb1 lb2 lb2 lb2 lb0 lb2 lb1 lb2 lb2 lb2 lb0 lb lb | l l l l l. Quelle(A) shared private slave unbind _ Ziel(B) shared shared shared slave+shared ungültig nicht gemeinsam shared private slave ungültig .TE .sp 1 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.) .PP .\" Für weitere Details siehe \fIDocumentation/filesystems/sharedsubtree.txt\fP in dem Kernelquellbaum. .SS "Semantik von Move (MS_MOVE)" Nehmen wir an, dass der folgende Befehl ausgeführt wird: .PP .in +4n .EX mount \-\-move A B/b .EE .in .PP Hier ist \fIA\fP der Quelleinhängepunkt, \fIB\fP der Zieleinhängepunkt und \fIb\fP ist der Unterverzeichnispfad unter dem Einhängepunkt \fIB\fP. Der Weiterleitungstyp der entstehenden Einhängung \fIB/b\fP hängt von den Weiterleitungstypen der Einhängepunkte \fIA\fP und \fIB\fP ab und wird in der nachfolgenden Tabelle zusammengefasst. .PP .TS lb2 lb1 lb2 lb2 lb2 lb0 lb2 lb1 lb2 lb2 lb2 lb0 lb lb | l l l l l. Quelle(A) shared private slave unbind _ Ziel(B) shared shared shared slave+shared ungültig nicht gemeinsam shared private slave unbindable .TE .sp 1 Hinweis: Das Verschieben einer Einhängung, die sich unter einer gemeinsamen Einhängung befindet, ist ungültig. .PP .\" Für weitere Details siehe \fIDocumentation/filesystems/sharedsubtree.txt\fP in dem Kernelquellbaum. .SS Einhänge\-Semantik Angenommen, wir verwenden folgenden Befehl, um einen Einhängepunkt zu erstellen: .PP .in +4n .EX mount Gerät B/b .EE .in .PP .\" Hier ist \fIB\fP der Zieleinhängepunkt und \fIb\fP der Unterverzeichnispfad unter dem Einhängepunkt \fIB\fP. Der Weiterleitungstyp der entstehenden Einhängung \fIB/b\fP 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. .SS Aushänge\-Semantik Angenommen, wir verwenden folgenden Befehl, um einen Einhängepunkt aufzulösen: .PP .in +4n .EX umount A .EE .in .PP .\" Hier ist \fIA\fP ein Einhängepunkt auf \fIB/b\fP, wobei \fIB\fP der Elterneinhängepunkt und \fIb\fP ein Unterverzeichnispfad unterhalb des Einhängepunkts \fIB\fP ist. Falls \fBB\fP gemeinsam ist, dann werden alle kürzlich eingehängten Einhängungen ausgehängt, die sich bei \fIb\fP befinden, die Weiterleitungen von der Einhängung \fIB\fP erhalten und keine Untereinhängungen haben. .SS "Die /proc/[PID]/mountinfo\-Markierung propagate_from" Die Markierung \fIpropagate_from:X\fP wird in den optionalen Feldern des Datensatzes \fI/proc/[PID]/mountinfo\fP 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. .PP In dem folgenden Beispiel erstellen wir zuerst eine Kette aus zwei Gliedern zwischen Master und Abhängiger, zwischen den Einhängungen \fI/mnt\fP, \fI/tmp/etc\fP und \fI/mnt/tmp/etc\fP. Dann wird der Befehl \fBchroot\fP(1) verwandt, um den Einhängepunkt \fI/tmp/etc\fP vom Wurzelverzeichnis unerreichbar zu bekommen und damit eine Situation zu erstellen, bei der der Master von \fI/mnt/tmp/etc\fP nicht vom (neuen) Wurzelverzeichnis des Prozesses aus erreichbar ist. .PP Zuerst machen wir eine Einhängung mit der Option bind des Wurzelverzeichnisses auf \fI/mnt\fP und dann eine Einhängung mit der Option bind von \fI/proc\fP bei \fI/mnt/proc\fP, so dass nach einem späteren \fBchroot\fP(1) das Dateisystem \fBproc\fP(5) an dem korrekten Ort in der Umgebung innerhalb des Chroots sichtbar bleibt. .PP .in +4n .EX # \fBmkdir \-p /mnt/proc\fP # \fBmount \-\-bind / /mnt\fP # \fBmount \-\-bind /proc /mnt/proc\fP .EE .in .PP Als nächstes stellen wir sicher, dass die Einhängung \fI/mnt\fP eine gemeinsame Einhängung in der neuen Gemeinschaftsgruppe (ohne weitere Mitglieder) ist: .PP .in +4n .EX # \fBmount \-\-make\-private /mnt\fP # Von jeder vorherigen Gemeinschaftsgruppe isolieren # \fBmount \-\-make\-shared /mnt\fP # \fBcat /proc/self/mountinfo | grep \(aq/mnt\(aq | sed \(aqs/ \- .*//\(aq\fP 239 61 8:2 / /mnt … shared:102 248 239 0:4 / /mnt/proc … shared:5 .EE .in .PP Als nächstes hängen wir \fI/mnt/etc\fP auf \fI/tmp/etc\fP mit der Option bind ein: .PP .in +4n .EX # \fBmkdir \-p /tmp/etc\fP # \fBmount \-\-bind /mnt/etc /tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP 239 61 8:2 / /mnt … shared:102 248 239 0:4 / /mnt/proc … shared:5 267 40 8:2 /etc /tmp/etc … shared:102 .EE .in .PP Anfänglich sind diese zwei Einhängepunkte in der gleichen Gemeinschaftsgruppe, aber dann machen wir \fI/tmp/etc\fP eine Abhängige von \fI/mnt/etc\fP, und dann machen wir \fI/tmp/etc\fP auch gemeinsam, so dass es Ereignisse an die nächste Abhängige in der Kette weiterleiten kann: .PP .in +4n .EX # \fBmount \-\-make\-slave /tmp/etc\fP # \fBmount \-\-make\-shared /tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP Dann hängen wir \fI/tmp/etc\fP auf \fI/mnt/tmp/etc\fP mit der Option bind ein. Wieder sind die zwei Einhängepunkte anfänglich in der gleichen Gemeinschaftsgruppe, aber wir machen \fI/mnt/tmp/etc\fP eine Abhängige von \fI/tmp/etc\fP: .PP .in +4n .EX # \fBmkdir \-p /mnt/tmp/etc\fP # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP # \fBmount \-\-make\-slave /mnt/tmp/etc\fP # \fBcat /proc/self/mountinfo | egrep \(aq/mnt|/tmp/\(aq | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP In vorhergehender Ausgabe können wir sehen, dass \fI/mnt\fP der Master der Abhängigen \fI/tmp/etc\fP ist, die wiederum der Master der Abhängigen \fI/mnt/tmp/etc\fP ist. .PP Dann wechseln wir mit \fBchroot\fP(1) zu dem Verzeichnis \fI/mnt\fP, wodurch die Einhängung mit der Kennung 267 vom (neuen) Wurzelverzeichnis aus nicht mehr erreichbar ist: .PP .in +4n .EX # \fBchroot /mnt\fP .EE .in .PP Wenn wir den Zustand der Einhängungen innerhalb der Chroot\-Umgebung untersuchen, sehen wir folgendes: .PP .in +4n .EX # \fBcat /proc/self/mountinfo | sed \(aqs/ \- .*//\(aq\fP 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 .EE .in .PP .\" 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 \fIpropagate_from\fP 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 \fI/mnt\fP entspricht, bevor der \fBchroot\fP(1) durchgeführt wurde.) .SH VERSIONEN Einhängenamensräume erschienen erstmalig in Linux 2.4.19. .SH "KONFORM ZU" .\" Namensräume sind eine Linux\-spezifische Funktionalität. .SH 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 \fBMS_SHARED\fP ist, dann ist der Weiterleitungstyp der neuen Einhängung auch \fBMS_SHARED\fP. Andernfalls ist der Einhängungstyp der neuen Einhängung \fBMS_PRIVATE\fP. .PP Unbenommen der Tatsache, dass der Standard\-Weiterleitungstyp für neue Einhängepunkte in vielen Fällen \fBMS_PRIVATE\fP ist, ist \fBMS_SHARED\fP normalerweise nützlicher. Aus diesem Grund hängt \fBsystemd\fP(1) beim Systemstart alle Einhängepunkte neu mit \fBMS_SHARED\fP ein. Daher ist auf modernen Systemen der Standard\-Weiterleitungstyp in der Praxis \fBMS_SHARED\fP. .PP Da bei der Verwendung von \fBunshare\fP(1) typischerweise das Ziel darin besteht, vollständige Isolierung der Einhängepunkte in dem neuen Namensraum zu erreichen, kehrt \fBunshare\fP(1) (seit \fIutil\-linux\fP Version 2.27) den durch \fBsystemd\fP(1) durchgeführten Schritt um, indem es in dem neuen Namensraum alle Einhängepunkte zu privaten macht. Das bedeutet, \fBunshare\fP(1) führt das Äquivalent des folgenden Befehls im neuen Namensraum aus: .PP .in +4n .EX mount \-\-make\-rprivate / .EE .in .PP Um dies zu verhindern, können Sie die Option \fI\-\-propagation\ unchanged\fP für \fBunshare\fP(1) verwenden. .PP Eine Anwendung, die einen neuen Einhängenamensraum direkt mit \fBclone\fP(2) oder \fBunshare\fP(2) erzeugt, könnte den Wunsch haben, die Weiterleitung von Einhängeereignissen in andere Einhängenamensräume zu verhindern (wie dies durch \fBunshare\fP(1) erfolgt). Dies kann durch Änderung des Einhängetyps von Einhängepunkten in dem neuen Namensraum auf entweder \fBMS_SLAVE\fP oder \fBMS_PRIVATE\fP erfolgen, indem ein Aufruf folgender Art erfolgt: .PP .in +4n .EX mount(NULL, "/", MS_SLAVE | MS_REC, NULL); .EE .in .PP Für eine Diskussion von Weiterleitungstypen beim Verschieben von Einhängungen (\fBMS_MOVE\fP) und der Erstellung von Einhängungen mit der Option bind (\fBMS_BIND\fP) siehe \fIDocumentation/filesystems/sharedsubtree.txt\fP. .SH BEISPIELE Siehe \fBpivot_root\fP(2). .SH "SIEHE AUCH" \fBunshare\fP(1), \fBclone\fP(2), \fBmount\fP(2), \fBpivot_root\fP(2), \fBsetns\fP(2), \fBumount\fP(2), \fBunshare\fP(2), \fBproc\fP(5), \fBnamespaces\fP(7), \fBuser_namespaces\fP(7), \fBfindmnt\fP(8), \fBmount\fP(8), \fBpivot_root\fP(8), \fBumount\fP(8) .PP \fIDocumentation/filesystems/sharedsubtree.txt\fP im Kernelquellbaum. .SH KOLOPHON Diese Seite ist Teil der Veröffentlichung 5.10 des Projekts Linux\-\fIman\-pages\fP. 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/. .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 .