1MOUNT_NAMESPACES(7) Linux Programmer's Manual MOUNT_NAMESPACES(7)
2
6 mount_namespaces - overview of Linux mount namespaces
7
9 For an overview of namespaces, see namespaces(7).
10 Mount namespaces provide isolation of the list of mount points seen by
12 the processes in each namespace instance. Thus, the processes in each
13 of the mount namespace instances will see distinct single-directory
14 hierarchies.
15 The views provided by the /proc/[pid]/mounts, /proc/[pid]/mountinfo,
17 and /proc/[pid]/mountstats files (all described in proc(5)) correspond
18 to the mount namespace in which the process with the PID [pid] resides.
19 (All of the processes that reside in the same mount namespace will see
20 the same view in these files.)
21 When a process creates a new mount namespace using clone(2) or
23 unshare(2) with the CLONE_NEWNS flag, the mount point list for the new
24 namespace is a copy of the caller's mount point list. Subsequent modi‐
25 fications to the mount point list (mount(2) and umount(2)) in either
26 mount namespace will not (by default) affect the mount point list seen
27 in the other namespace (but see the following discussion of shared sub‐
28 trees).
29 Restrictions on mount namespaces
31 Note the following points with respect to mount namespaces:
32 * A mount namespace has an owner user namespace. A mount namespace
34 whose owner user namespace is different from the owner user names‐
35 pace of its parent mount namespace is considered a less privileged
36 mount namespace.
37 * When creating a less privileged mount namespace, shared mounts are
39 reduced to slave mounts. (Shared and slave mounts are discussed
40 below.) This ensures that mappings performed in less privileged
41 mount namespaces will not propagate to more privileged mount names‐
42 paces.
43 * Mounts that come as a single unit from more privileged mount are
45 locked together and may not be separated in a less privileged mount
46 namespace. (The unshare(2) CLONE_NEWNS operation brings across all
47 of the mounts from the original mount namespace as a single unit,
48 and recursive mounts that propagate between mount namespaces propa‐
49 gate as a single unit.)
50 * The mount(2) flags MS_RDONLY, MS_NOSUID, MS_NOEXEC, and the "atime"
52 flags (MS_NOATIME, MS_NODIRATIME, MS_RELATIME) settings become
53 locked when propagated from a more privileged to a less privileged
54 mount namespace, and may not be changed in the less privileged mount
55 namespace.
56 * A file or directory that is a mount point in one namespace that is
58 not a mount point in another namespace, may be renamed, unlinked, or
59 removed (rmdir(2)) in the mount namespace in which it is not a mount
60 point (subject to the usual permission checks).
61 Previously, attempting to unlink, rename, or remove a file or direc‐
63 tory that was a mount point in another mount namespace would result
64 in the error EBUSY. That behavior had technical problems of
65 enforcement (e.g., for NFS) and permitted denial-of-service attacks
66 against more privileged users. (i.e., preventing individual files
67 from being updated by bind mounting on top of them).
68
70 After the implementation of mount namespaces was completed, experience
71 showed that the isolation that they provided was, in some cases, too
72 great. For example, in order to make a newly loaded optical disk
73 available in all mount namespaces, a mount operation was required in
74 each namespace. For this use case, and others, the shared subtree fea‐
75 ture was introduced in Linux 2.6.15. This feature allows for auto‐
76 matic, controlled propagation of mount and unmount events between
77 namespaces (or, more precisely, between the members of a peer group
78 that are propagating events to one another).
79 Each mount point is marked (via mount(2)) as having one of the follow‐
81 ing propagation types:
82 MS_SHARED
84 This mount point shares events with members of a peer group.
85 Mount and unmount events immediately under this mount point will
86 propagate to the other mount points that are members of the peer
87 group. Propagation here means that the same mount or unmount
88 will automatically occur under all of the other mount points in
89 the peer group. Conversely, mount and unmount events that take
90 place under peer mount points will propagate to this mount
91 point.
92 MS_PRIVATE
94 This mount point is private; it does not have a peer group.
95 Mount and unmount events do not propagate into or out of this
96 mount point.
97 MS_SLAVE
99 Mount and unmount events propagate into this mount point from a
100 (master) shared peer group. Mount and unmount events under this
101 mount point do not propagate to any peer.
102 Note that a mount point can be the slave of another peer group
104 while at the same time sharing mount and unmount events with a
105 peer group of which it is a member. (More precisely, one peer
106 group can be the slave of another peer group.)
107 MS_UNBINDABLE
109 This is like a private mount, and in addition this mount can't
110 be bind mounted. Attempts to bind mount this mount (mount(2)
111 with the MS_BIND flag) will fail.
112 When a recursive bind mount (mount(2) with the MS_BIND and
114 MS_REC flags) is performed on a directory subtree, any bind
115 mounts within the subtree are automatically pruned (i.e., not
116 replicated) when replicating that subtree to produce the target
117 subtree.
118 For a discussion of the propagation type assigned to a new mount, see
120 NOTES.
121 The propagation type is a per-mount-point setting; some mount points
123 may be marked as shared (with each shared mount point being a member of
124 a distinct peer group), while others are private (or slaved or unbind‐
125 able).
126 Note that a mount's propagation type determines whether mounts and
128 unmounts of mount points immediately under the mount point are propa‐
129 gated. Thus, the propagation type does not affect propagation of
130 events for grandchildren and further removed descendant mount points.
131 What happens if the mount point itself is unmounted is determined by
132 the propagation type that is in effect for the parent of the mount
133 point.
134 Members are added to a peer group when a mount point is marked as
136 shared and either:
137 * the mount point is replicated during the creation of a new mount
139 namespace; or
140 * a new bind mount is created from the mount point.
142 In both of these cases, the new mount point joins the peer group of
144 which the existing mount point is a member.
145 A new peer group is also created when a child mount point is created
147 under an existing mount point that is marked as shared. In this case,
148 the new child mount point is also marked as shared and the resulting
149 peer group consists of all the mount points that are replicated under
150 the peers of parent mount.
151 A mount ceases to be a member of a peer group when either the mount is
153 explicitly unmounted, or when the mount is implicitly unmounted because
154 a mount namespace is removed (because it has no more member processes).
155 The propagation type of the mount points in a mount namespace can be
157 discovered via the "optional fields" exposed in /proc/[pid]/mountinfo.
158 (See proc(5) for details of this file.) The following tags can appear
159 in the optional fields for a record in that file:
160 shared:X
162 This mount point is shared in peer group X. Each peer group has
163 a unique ID that is automatically generated by the kernel, and
164 all mount points in the same peer group will show the same ID.
165 (These IDs are assigned starting from the value 1, and may be
166 recycled when a peer group ceases to have any members.)
167 master:X
169 This mount is a slave to shared peer group X.
170 propagate_from:X (since Linux 2.6.26)
172 This mount is a slave and receives propagation from shared peer
173 group X. This tag will always appear in conjunction with a mas‐
174 ter:X tag. Here, X is the closest dominant peer group under the
175 process's root directory. If X is the immediate master of the
176 mount, or if there is no dominant peer group under the same
177 root, then only the master:X field is present and not the propa‐
178 gate_from:X field. For further details, see below.
179 unbindable
181 This is an unbindable mount.
182 If none of the above tags is present, then this is a private mount.
184 MS_SHARED and MS_PRIVATE example
186 Suppose that on a terminal in the initial mount namespace, we mark one
187 mount point as shared and another as private, and then view the mounts
188 in /proc/self/mountinfo:
189 sh1# mount --make-shared /mntS
191 sh1# mount --make-private /mntP
192 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
193 77 61 8:17 / /mntS rw,relatime shared:1
194 83 61 8:15 / /mntP rw,relatime
195 From the /proc/self/mountinfo output, we see that /mntS is a shared
197 mount in peer group 1, and that /mntP has no optional tags, indicating
198 that it is a private mount. The first two fields in each record in
199 this file are the unique ID for this mount, and the mount ID of the
200 parent mount. We can further inspect this file to see that the parent
201 mount point of /mntS and /mntP is the root directory, /, which is
202 mounted as private:
203 sh1# cat /proc/self/mountinfo | awk '$1 == 61' | sed 's/ - .*//'
205 61 0 8:2 / / rw,relatime
206 On a second terminal, we create a new mount namespace where we run a
208 second shell and inspect the mounts:
209 $ PS1='sh2# ' sudo unshare -m --propagation unchanged sh
211 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
212 222 145 8:17 / /mntS rw,relatime shared:1
213 225 145 8:15 / /mntP rw,relatime
214 The new mount namespace received a copy of the initial mount names‐
216 pace's mount points. These new mount points maintain the same propaga‐
217 tion types, but have unique mount IDs. (The --propagation unchanged
218 option prevents unshare(1) from marking all mounts as private when cre‐
219 ating a new mount namespace, which it does by default.)
220 In the second terminal, we then create submounts under each of /mntS
222 and /mntP and inspect the set-up:
223 sh2# mkdir /mntS/a
225 sh2# mount /dev/sdb6 /mntS/a
226 sh2# mkdir /mntP/b
227 sh2# mount /dev/sdb7 /mntP/b
228 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
229 222 145 8:17 / /mntS rw,relatime shared:1
230 225 145 8:15 / /mntP rw,relatime
231 178 222 8:22 / /mntS/a rw,relatime shared:2
232 230 225 8:23 / /mntP/b rw,relatime
233 From the above, it can be seen that /mntS/a was created as shared
235 (inheriting this setting from its parent mount) and /mntP/b was created
236 as a private mount.
237 Returning to the first terminal and inspecting the set-up, we see that
239 the new mount created under the shared mount point /mntS propagated to
240 its peer mount (in the initial mount namespace), but the new mount cre‐
241 ated under the private mount point /mntP did not propagate:
242 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
244 77 61 8:17 / /mntS rw,relatime shared:1
245 83 61 8:15 / /mntP rw,relatime
246 179 77 8:22 / /mntS/a rw,relatime shared:2
247 MS_SLAVE example
249 Making a mount point a slave allows it to receive propagated mount and
250 unmount events from a master shared peer group, while preventing it
251 from propagating events to that master. This is useful if we want to
252 (say) receive a mount event when an optical disk is mounted in the mas‐
253 ter shared peer group (in another mount namespace), but want to prevent
254 mount and unmount events under the slave mount from having side effects
255 in other namespaces.
256 We can demonstrate the effect of slaving by first marking two mount
258 points as shared in the initial mount namespace:
259 sh1# mount --make-shared /mntX
261 sh1# mount --make-shared /mntY
262 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
263 132 83 8:23 / /mntX rw,relatime shared:1
264 133 83 8:22 / /mntY rw,relatime shared:2
265 On a second terminal, we create a new mount namespace and inspect the
267 mount points:
268 sh2# unshare -m --propagation unchanged sh
270 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
271 168 167 8:23 / /mntX rw,relatime shared:1
272 169 167 8:22 / /mntY rw,relatime shared:2
273 In the new mount namespace, we then mark one of the mount points as a
275 slave:
276 sh2# mount --make-slave /mntY
278 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
279 168 167 8:23 / /mntX rw,relatime shared:1
280 169 167 8:22 / /mntY rw,relatime master:2
281 From the above output, we see that /mntY is now a slave mount that is
283 receiving propagation events from the shared peer group with the ID 2.
284 Continuing in the new namespace, we create submounts under each of
286 /mntX and /mntY:
287 sh2# mkdir /mntX/a
289 sh2# mount /dev/sda3 /mntX/a
290 sh2# mkdir /mntY/b
291 sh2# mount /dev/sda5 /mntY/b
292 When we inspect the state of the mount points in the new mount names‐
294 pace, we see that /mntX/a was created as a new shared mount (inheriting
295 the "shared" setting from its parent mount) and /mntY/b was created as
296 a private mount:
297 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
299 168 167 8:23 / /mntX rw,relatime shared:1
300 169 167 8:22 / /mntY rw,relatime master:2
301 173 168 8:3 / /mntX/a rw,relatime shared:3
302 175 169 8:5 / /mntY/b rw,relatime
303 Returning to the first terminal (in the initial mount namespace), we
305 see that the mount /mntX/a propagated to the peer (the shared /mntX),
306 but the mount /mntY/b was not propagated:
307 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
309 132 83 8:23 / /mntX rw,relatime shared:1
310 133 83 8:22 / /mntY rw,relatime shared:2
311 174 132 8:3 / /mntX/a rw,relatime shared:3
312 Now we create a new mount point under /mntY in the first shell:
314 sh1# mkdir /mntY/c
316 sh1# mount /dev/sda1 /mntY/c
317 sh1# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
318 132 83 8:23 / /mntX rw,relatime shared:1
319 133 83 8:22 / /mntY rw,relatime shared:2
320 174 132 8:3 / /mntX/a rw,relatime shared:3
321 178 133 8:1 / /mntY/c rw,relatime shared:4
322 When we examine the mount points in the second mount namespace, we see
324 that in this case the new mount has been propagated to the slave mount
325 point, and that the new mount is itself a slave mount (to peer group
326 4):
327 sh2# cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
329 168 167 8:23 / /mntX rw,relatime shared:1
330 169 167 8:22 / /mntY rw,relatime master:2
331 173 168 8:3 / /mntX/a rw,relatime shared:3
332 175 169 8:5 / /mntY/b rw,relatime
333 179 169 8:1 / /mntY/c rw,relatime master:4
334 MS_UNBINDABLE example
336 One of the primary purposes of unbindable mounts is to avoid the "mount
337 point explosion" problem when repeatedly performing bind mounts of a
338 higher-level subtree at a lower-level mount point. The problem is
339 illustrated by the following shell session.
340 Suppose we have a system with the following mount points:
342 # mount | awk '{print $1, $2, $3}'
344 /dev/sda1 on /
345 /dev/sdb6 on /mntX
346 /dev/sdb7 on /mntY
347 Suppose furthermore that we wish to recursively bind mount the root
349 directory under several users' home directories. We do this for the
350 first user, and inspect the mount points:
351 # mount --rbind / /home/cecilia/
353 # mount | awk '{print $1, $2, $3}'
354 /dev/sda1 on /
355 /dev/sdb6 on /mntX
356 /dev/sdb7 on /mntY
357 /dev/sda1 on /home/cecilia
358 /dev/sdb6 on /home/cecilia/mntX
359 /dev/sdb7 on /home/cecilia/mntY
360 When we repeat this operation for the second user, we start to see the
362 explosion problem:
363 # mount --rbind / /home/henry
365 # mount | awk '{print $1, $2, $3}'
366 /dev/sda1 on /
367 /dev/sdb6 on /mntX
368 /dev/sdb7 on /mntY
369 /dev/sda1 on /home/cecilia
370 /dev/sdb6 on /home/cecilia/mntX
371 /dev/sdb7 on /home/cecilia/mntY
372 /dev/sda1 on /home/henry
373 /dev/sdb6 on /home/henry/mntX
374 /dev/sdb7 on /home/henry/mntY
375 /dev/sda1 on /home/henry/home/cecilia
376 /dev/sdb6 on /home/henry/home/cecilia/mntX
377 /dev/sdb7 on /home/henry/home/cecilia/mntY
378 Under /home/henry, we have not only recursively added the /mntX and
380 /mntY mounts, but also the recursive mounts of those directories under
381 /home/cecilia that were created in the previous step. Upon repeating
382 the step for a third user, it becomes obvious that the explosion is
383 exponential in nature:
384 # mount --rbind / /home/otto
386 # mount | awk '{print $1, $2, $3}'
387 /dev/sda1 on /
388 /dev/sdb6 on /mntX
389 /dev/sdb7 on /mntY
390 /dev/sda1 on /home/cecilia
391 /dev/sdb6 on /home/cecilia/mntX
392 /dev/sdb7 on /home/cecilia/mntY
393 /dev/sda1 on /home/henry
394 /dev/sdb6 on /home/henry/mntX
395 /dev/sdb7 on /home/henry/mntY
396 /dev/sda1 on /home/henry/home/cecilia
397 /dev/sdb6 on /home/henry/home/cecilia/mntX
398 /dev/sdb7 on /home/henry/home/cecilia/mntY
399 /dev/sda1 on /home/otto
400 /dev/sdb6 on /home/otto/mntX
401 /dev/sdb7 on /home/otto/mntY
402 /dev/sda1 on /home/otto/home/cecilia
403 /dev/sdb6 on /home/otto/home/cecilia/mntX
404 /dev/sdb7 on /home/otto/home/cecilia/mntY
405 /dev/sda1 on /home/otto/home/henry
406 /dev/sdb6 on /home/otto/home/henry/mntX
407 /dev/sdb7 on /home/otto/home/henry/mntY
408 /dev/sda1 on /home/otto/home/henry/home/cecilia
409 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
410 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
411 The mount explosion problem in the above scenario can be avoided by
413 making each of the new mounts unbindable. The effect of doing this is
414 that recursive mounts of the root directory will not replicate the
415 unbindable mounts. We make such a mount for the first user:
416 # mount --rbind --make-unbindable / /home/cecilia
418 Before going further, we show that unbindable mounts are indeed unbind‐
420 able:
421 # mkdir /mntZ
423 # mount --bind /home/cecilia /mntZ
424 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
425 missing codepage or helper program, or other error
426 In some cases useful info is found in syslog - try
428 dmesg | tail or so.
429 Now we create unbindable recursive bind mounts for the other two users:
431 # mount --rbind --make-unbindable / /home/henry
433 # mount --rbind --make-unbindable / /home/otto
434 Upon examining the list of mount points, we see there has been no
436 explosion of mount points, because the unbindable mounts were not
437 replicated under each user's directory:
438 # mount | awk '{print $1, $2, $3}'
440 /dev/sda1 on /
441 /dev/sdb6 on /mntX
442 /dev/sdb7 on /mntY
443 /dev/sda1 on /home/cecilia
444 /dev/sdb6 on /home/cecilia/mntX
445 /dev/sdb7 on /home/cecilia/mntY
446 /dev/sda1 on /home/henry
447 /dev/sdb6 on /home/henry/mntX
448 /dev/sdb7 on /home/henry/mntY
449 /dev/sda1 on /home/otto
450 /dev/sdb6 on /home/otto/mntX
451 /dev/sdb7 on /home/otto/mntY
452 Propagation type transitions
454 The following table shows the effect that applying a new propagation
455 type (i.e., mount --make-xxxx) has on the existing propagation type of
456 a mount point. The rows correspond to existing propagation types, and
457 the columns are the new propagation settings. For reasons of space,
458 "private" is abbreviated as "priv" and "unbindable" as "unbind".
459 make-shared make-slave make-priv make-unbind
461 shared shared slave/priv [1] priv unbind
462 slave slave+shared slave [2] priv unbind
464 slave+shared slave+shared slave priv unbind
465 private shared priv [2] priv unbind
466 unbindable shared unbind [2] priv unbind
467 Note the following details to the table:
469 [1] If a shared mount is the only mount in its peer group, making it a
471 slave automatically makes it private.
472 [2] Slaving a nonshared mount has no effect on the mount.
474 Bind (MS_BIND) semantics
476 Suppose that the following command is performed:
477 mount --bind A/a B/b
479 Here, A is the source mount point, B is the destination mount point, a
481 is a subdirectory path under the mount point A, and b is a subdirectory
482 path under the mount point B. The propagation type of the resulting
483 mount, B/b, depends on the propagation types of the mount points A and
484 B, and is summarized in the following table.
485 source(A)
487 shared private slave unbind
488 ───────────────────────────────────────────────────────────────
489 dest(B) shared | shared shared slave+shared invalid
490 nonshared | shared private slave invalid
491 Note that a recursive bind of a subtree follows the same semantics as
493 for a bind operation on each mount in the subtree. (Unbindable mounts
494 are automatically pruned at the target mount point.)
495 For further details, see Documentation/filesystems/sharedsubtree.txt in
497 the kernel source tree.
498 Move (MS_MOVE) semantics
500 Suppose that the following command is performed:
501 mount --move A B/b
503 Here, A is the source mount point, B is the destination mount point,
505 and b is a subdirectory path under the mount point B. The propagation
506 type of the resulting mount, B/b, depends on the propagation types of
507 the mount points A and B, and is summarized in the following table.
508 source(A)
510 shared private slave unbind
511 ──────────────────────────────────────────────────────────────────
512 dest(B) shared | shared shared slave+shared invalid
513 nonshared | shared private slave unbindable
514 Note: moving a mount that resides under a shared mount is invalid.
516 For further details, see Documentation/filesystems/sharedsubtree.txt in
518 the kernel source tree.
519 Mount semantics
521 Suppose that we use the following command to create a mount point:
522 mount device B/b
524 Here, B is the destination mount point, and b is a subdirectory path
526 under the mount point B. The propagation type of the resulting mount,
527 B/b, follows the same rules as for a bind mount, where the propagation
528 type of the source mount is considered always to be private.
529 Unmount semantics
531 Suppose that we use the following command to tear down a mount point:
532 unmount A
534 Here, A is a mount point on B/b, where B is the parent mount and b is a
536 subdirectory path under the mount point B. If B is shared, then all
537 most-recently-mounted mounts at b on mounts that receive propagation
538 from mount B and do not have submounts under them are unmounted.
539 The /proc/[pid]/mountinfo propagate_from tag
541 The propagate_from:X tag is shown in the optional fields of a
542 /proc/[pid]/mountinfo record in cases where a process can't see a
543 slave's immediate master (i.e., the pathname of the master is not
544 reachable from the filesystem root directory) and so cannot determine
545 the chain of propagation between the mounts it can see.
546 In the following example, we first create a two-link master-slave chain
548 between the mounts /mnt, /tmp/etc, and /mnt/tmp/etc. Then the
549 chroot(1) command is used to make the /tmp/etc mount point unreachable
550 from the root directory, creating a situation where the master of
551 /mnt/tmp/etc is not reachable from the (new) root directory of the
552 process.
553 First, we bind mount the root directory onto /mnt and then bind mount
555 /proc at /mnt/proc so that after the later chroot(1) the proc(5)
556 filesystem remains visible at the correct location in the chroot-ed
557 environment.
558 # mkdir -p /mnt/proc
560 # mount --bind / /mnt
561 # mount --bind /proc /mnt/proc
562 Next, we ensure that the /mnt mount is a shared mount in a new peer
564 group (with no peers):
565 # mount --make-private /mnt # Isolate from any previous peer group
567 # mount --make-shared /mnt
568 # cat /proc/self/mountinfo | grep '/mnt' | sed 's/ - .*//'
569 239 61 8:2 / /mnt ... shared:102
570 248 239 0:4 / /mnt/proc ... shared:5
571 Next, we bind mount /mnt/etc onto /tmp/etc:
573 # mkdir -p /tmp/etc
575 # mount --bind /mnt/etc /tmp/etc
576 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
577 239 61 8:2 / /mnt ... shared:102
578 248 239 0:4 / /mnt/proc ... shared:5
579 267 40 8:2 /etc /tmp/etc ... shared:102
580 Initially, these two mount points are in the same peer group, but we
582 then make the /tmp/etc a slave of /mnt/etc, and then make /tmp/etc
583 shared as well, so that it can propagate events to the next slave in
584 the chain:
585 # mount --make-slave /tmp/etc
587 # mount --make-shared /tmp/etc
588 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
589 239 61 8:2 / /mnt ... shared:102
590 248 239 0:4 / /mnt/proc ... shared:5
591 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
592 Then we bind mount /tmp/etc onto /mnt/tmp/etc. Again, the two mount
594 points are initially in the same peer group, but we then make
595 /mnt/tmp/etc a slave of /tmp/etc:
596 # mkdir -p /mnt/tmp/etc
598 # mount --bind /tmp/etc /mnt/tmp/etc
599 # mount --make-slave /mnt/tmp/etc
600 # cat /proc/self/mountinfo | egrep '/mnt|/tmp/' | sed 's/ - .*//'
601 239 61 8:2 / /mnt ... shared:102
602 248 239 0:4 / /mnt/proc ... shared:5
603 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
604 273 239 8:2 /etc /mnt/tmp/etc ... master:105
605 From the above, we see that /mnt is the master of the slave /tmp/etc,
607 which in turn is the master of the slave /mnt/tmp/etc.
608 We then chroot(1) to the /mnt directory, which renders the mount with
610 ID 267 unreachable from the (new) root directory:
611 # chroot /mnt
613 When we examine the state of the mounts inside the chroot-ed environ‐
615 ment, we see the following:
616 # cat /proc/self/mountinfo | sed 's/ - .*//'
618 239 61 8:2 / / ... shared:102
619 248 239 0:4 / /proc ... shared:5
620 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
621 Above, we see that the mount with ID 273 is a slave whose master is the
623 peer group 105. The mount point for that master is unreachable, and so
624 a propagate_from tag is displayed, indicating that the closest dominant
625 peer group (i.e., the nearest reachable mount in the slave chain) is
626 the peer group with the ID 102 (corresponding to the /mnt mount point
627 before the chroot(1) was performed.
628
630 Mount namespaces first appeared in Linux 2.4.19.
631
633 Namespaces are a Linux-specific feature.
634
636 The propagation type assigned to a new mount point depends on the prop‐
637 agation type of the parent directory. If the mount point has a parent
638 (i.e., it is a non-root mount point) and the propagation type of the
639 parent is MS_SHARED, then the propagation type of the new mount is also
640 MS_SHARED. Otherwise, the propagation type of the new mount is MS_PRI‐
641 VATE. But see also NOTES.
642 Notwithstanding the fact that the default propagation type for new
644 mount points is in many cases MS_PRIVATE, MS_SHARED is typically more
645 useful. For this reason, systemd(1) automatically remounts all mount
646 points as MS_SHARED on system startup. Thus, on most modern systems,
647 the default propagation type is in practice MS_SHARED.
648 Since, when one uses unshare(1) to create a mount namespace, the goal
650 is commonly to provide full isolation of the mount points in the new
651 namespace, unshare(1) (since util-linux version 2.27) in turn reverses
652 the step performed by systemd(1), by making all mount points private in
653 the new namespace. That is, unshare(1) performs the equivalent of the
654 following in the new mount namespace:
655 mount --make-rprivate /
657 To prevent this, one can use the --propagation unchanged option to
659 unshare(1).
660 For a discussion of propagation types when moving mounts (MS_MOVE) and
662 creating bind mounts (MS_BIND), see Documentation/filesystems/shared‐
663 subtree.txt.
664
666 unshare(1), clone(2), mount(2), setns(2), umount(2), unshare(2),
667 proc(5), namespaces(7), user_namespaces(7)
668 Documentation/filesystems/sharedsubtree.txt in the kernel source tree.
670
672 This page is part of release 4.16 of the Linux man-pages project. A
673 description of the project, information about reporting bugs, and the
674 latest version of this page, can be found at
675 https://www.kernel.org/doc/man-pages/.
676Linux 2018-04-30 MOUNT_NAMESPACES(7)