diff options
Diffstat (limited to 'man7/mount_namespaces.7')
| -rw-r--r-- | man7/mount_namespaces.7 | 155 |
1 files changed, 78 insertions, 77 deletions
diff --git a/man7/mount_namespaces.7 b/man7/mount_namespaces.7 index 1f0a1b41f..1acb8763b 100644 --- a/man7/mount_namespaces.7 +++ b/man7/mount_namespaces.7 @@ -9,7 +9,7 @@ mount_namespaces \- overview of Linux mount namespaces .SH DESCRIPTION For an overview of namespaces, see -.BR namespaces (7). +.MR namespaces 7 . .P Mount namespaces provide isolation of the list of mounts seen by the processes in each namespace instance. @@ -22,7 +22,7 @@ The views provided by the and .IR /proc/ pid /mountstats files (all described in -.BR proc (5)) +.MR proc 5 ) correspond to the mount namespace in which the process with the PID .I pid resides. @@ -30,9 +30,9 @@ resides. will see the same view in these files.) .P A new mount namespace is created using either -.BR clone (2) +.MR clone 2 or -.BR unshare (2) +.MR unshare 2 with the .B CLONE_NEWNS flag. @@ -40,19 +40,19 @@ When a new mount namespace is created, its mount list is initialized as follows: .IP \[bu] 3 If the namespace is created using -.BR clone (2), +.MR clone 2 , the mount list of the child's namespace is a copy of the mount list in the parent process's mount namespace. .IP \[bu] If the namespace is created using -.BR unshare (2), +.MR unshare 2 , the mount list of the new namespace is a copy of the mount list in the caller's previous mount namespace. .P Subsequent modifications to the mount list .RB ( mount (2) and -.BR umount (2)) +.MR umount 2 ) in either mount namespace will not (by default) affect the mount list seen in the other namespace (but see the following discussion of shared subtrees). @@ -67,9 +67,9 @@ a mount operation was required in each namespace. For this use case, and others, the shared subtree feature was introduced in Linux 2.6.15. This feature allows for automatic, controlled propagation of -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 .I events between namespaces (or, more precisely, between the mounts that are members of a @@ -77,54 +77,54 @@ between namespaces that are propagating events to one another). .P Each mount is marked (via -.BR mount (2)) +.MR mount 2 ) as having one of the following .IR "propagation types" : .TP .B MS_SHARED This mount shares events with members of a peer group. -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events immediately under this mount will propagate to the other mounts that are members of the peer group. .I Propagation here means that the same -.BR mount (2) +.MR mount 2 or -.BR umount (2) +.MR umount 2 will automatically occur under all of the other mounts in the peer group. Conversely, -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events that take place under peer mounts will propagate to this mount. .TP .B MS_PRIVATE This mount is private; it does not have a peer group. -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events do not propagate into or out of this mount. .TP .B MS_SLAVE -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events propagate into this mount from a (master) shared peer group. -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events under this mount do not propagate to any peer. .IP Note that a mount can be the slave of another peer group while at the same time sharing -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events with a peer group of which it is a member. (More precisely, one peer group can be the slave of another peer group.) @@ -159,9 +159,9 @@ while others are private (or slaved or unbindable). .P Note that a mount's propagation type determines whether -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 of mounts .I immediately under the mount are propagated. @@ -198,7 +198,7 @@ The propagation type of the mounts in a mount namespace can be discovered via the "optional fields" exposed in .IR /proc/ pid /mountinfo . (See -.BR proc (5) +.MR proc 5 for details of this file.) The following tags can appear in the optional fields for a record in that file: @@ -301,7 +301,7 @@ but have unique mount IDs. (The .I \-\-propagation\~unchanged option prevents -.BR unshare (1) +.MR unshare 1 from marking all mounts as private when creating a new mount namespace, .\" Since util-linux 2.27 which it does by default.) @@ -351,18 +351,18 @@ sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq .\" .SS MS_SLAVE example Making a mount a slave allows it to receive propagated -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events from a master shared peer group, while preventing it from propagating events to that master. This is useful if we want to (say) receive a mount event when an optical disk is mounted in the master shared peer group (in another mount namespace), but want to prevent -.BR mount (2) +.MR mount 2 and -.BR umount (2) +.MR umount 2 events under the slave mount from having side effects in other namespaces. .P @@ -830,7 +830,7 @@ between the mounts and .IR /mnt/tmp/etc . Then the -.BR chroot (1) +.MR chroot 1 command is used to make the .I /tmp/etc mount point unreachable from the root directory, @@ -845,9 +845,9 @@ and then bind mount at .I /mnt/proc so that after the later -.BR chroot (1) +.MR chroot 1 the -.BR proc (5) +.MR proc 5 filesystem remains visible at the correct location in the chroot-ed environment. .P @@ -941,7 +941,7 @@ which in turn is the master of the slave .IR /mnt/tmp/etc . .P We then -.BR chroot (1) +.MR chroot 1 to the .I /mnt directory, which renders the mount with ID 267 unreachable @@ -974,7 +974,7 @@ tag is displayed, indicating that the closest dominant peer group is the peer group with the ID 102 (corresponding to the .I /mnt mount point before the -.BR chroot (1) +.MR chroot 1 was performed). .\" .SH STANDARDS @@ -999,7 +999,7 @@ for new mount is in many cases .B MS_SHARED is typically more useful. For this reason, -.BR systemd (1) +.MR systemd 1 automatically remounts all mounts as .B MS_SHARED on system startup. @@ -1007,18 +1007,18 @@ Thus, on most modern systems, the default propagation type is in practice .BR MS_SHARED . .P Since, when one uses -.BR unshare (1) +.MR unshare 1 to create a mount namespace, the goal is commonly to provide full isolation of the mounts in the new namespace, -.BR unshare (1) +.MR unshare 1 (since .I util\-linux 2.27) in turn reverses the step performed by -.BR systemd (1), +.MR systemd 1 , by making all mounts private in the new namespace. That is, -.BR unshare (1) +.MR unshare 1 performs the equivalent of the following in the new mount namespace: .P .in +4n @@ -1030,15 +1030,15 @@ mount \-\-make\-rprivate / To prevent this, one can use the .I \-\-propagation\~unchanged option to -.BR unshare (1). +.MR unshare 1 . .P An application that creates a new mount namespace directly using -.BR clone (2) +.MR clone 2 or -.BR unshare (2) +.MR unshare 2 may desire to prevent propagation of mount events to other mount namespaces (as is done by -.BR unshare (1)). +.MR unshare 1 ). This can be done by changing the propagation type of mounts in the new namespace to either .B MS_SLAVE @@ -1083,7 +1083,7 @@ Mounts that come as a single unit from a more privileged mount namespace are locked together and may not be separated in a less privileged mount namespace. (The -.BR unshare (2) +.MR unshare 2 .B CLONE_NEWNS operation brings across all of the mounts from the original mount namespace as a single unit, @@ -1107,7 +1107,7 @@ have created a bind mount that obscures the contents of the shadow password file, .IR /etc/shadow . For security reasons, it should not be possible to -.BR umount (2) +.MR umount 2 that mount in a less privileged mount namespace, since that would reveal the contents of .IR /etc/shadow . @@ -1119,7 +1119,7 @@ from the previous mount namespace. However, those mounts will be locked because the new mount namespace is less privileged. Consequently, an attempt to -.BR umount (2) +.MR umount 2 the mount fails as show in the following step: .IP @@ -1135,11 +1135,11 @@ umount2("/etc/shadow", 0) = \-1 EINVAL (Invalid argument) .in .IP The error message from -.BR mount (8) +.MR mount 8 is a little confusing, but the -.BR strace (1) +.MR strace 1 output reveals that the underlying -.BR umount2 (2) +.MR umount2 2 system call failed with the error .BR EINVAL , which is the error that the kernel returns to indicate that @@ -1160,7 +1160,7 @@ aaaaa .in .IP The final -.BR umount (8) +.MR umount 8 command above, which is performed in the initial mount namespace, makes the original .I /etc/shadow @@ -1168,13 +1168,13 @@ file once more visible in that namespace. .IP [4] Following on from point [3], note that it is possible to -.BR umount (2) +.MR umount 2 an entire subtree of mounts that propagated as a unit into a less privileged mount namespace, as illustrated in the following example. .IP First, we create new user and mount namespaces using -.BR unshare (1). +.MR unshare 1 . In the new mount namespace, the propagation type of all mounts is set to private. We then create a shared bind mount at @@ -1224,7 +1224,7 @@ This means that submount events will propagate from the master in "ns1", but propagation will not occur in the opposite direction. .IP From a separate terminal window, we then use -.BR nsenter (1) +.MR nsenter 1 to enter the mount and user namespaces corresponding to "ns1". In that terminal window, we then recursively bind mount .I /mnt/x @@ -1264,12 +1264,12 @@ ns2# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP .in .IP While it is not possible to -.BR umount (2) +.MR umount 2 a part of the propagated subtree .RI ( /mnt/ppp/y ) in "ns2", it is possible to -.BR umount (2) +.MR umount 2 the entire subtree, as shown by the following commands: .IP @@ -1286,7 +1286,7 @@ ns2# \fBgrep /mnt /proc/self/mountinfo\fP .in .IP [5] The -.BR mount (2) +.MR mount 2 flags .BR MS_RDONLY , .BR MS_NOSUID , @@ -1326,7 +1326,8 @@ mount: /mnt/dir: permission denied. .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree)) A file or directory that is a mount point in one namespace that is not a mount point in another namespace, may be renamed, unlinked, or removed -.RB ( rmdir (2)) +\%(\c +.MR rmdir 2 ) in the mount namespace in which it is not a mount point (subject to the usual permission checks). Consequently, the mount point is removed in the mount namespace @@ -1348,24 +1349,24 @@ and permitted denial-of-service attacks against more privileged users by bind mounting on top of them). .SH EXAMPLES See -.BR pivot_root (2). +.MR pivot_root 2 . .SH SEE ALSO -.BR unshare (1), -.BR clone (2), -.BR mount (2), -.BR mount_setattr (2), -.BR pivot_root (2), -.BR setns (2), -.BR umount (2), -.BR unshare (2), -.BR proc (5), -.BR namespaces (7), -.BR user_namespaces (7), -.BR findmnt (8), -.BR mount (8), -.BR pam_namespace (8), -.BR pivot_root (8), -.BR umount (8) +.MR unshare 1 , +.MR clone 2 , +.MR mount 2 , +.MR mount_setattr 2 , +.MR pivot_root 2 , +.MR setns 2 , +.MR umount 2 , +.MR unshare 2 , +.MR proc 5 , +.MR namespaces 7 , +.MR user_namespaces 7 , +.MR findmnt 8 , +.MR mount 8 , +.MR pam_namespace 8 , +.MR pivot_root 8 , +.MR umount 8 .P .I Documentation/filesystems/sharedsubtree.rst in the kernel source tree. |