| blob | c40aae96b19590b248ffabfa485c3ade32e8a529 |
1 '\" t
2 .\" Copyright (c) 2016, 2019, 2021 by Michael Kerrisk <mtk.manpages@gmail.com>
3 .\"
4 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
5 .\"
6 .\"
7 .TH mount_namespaces 7 (date) "Linux man-pages (unreleased)"
8 .SH NAME
9 mount_namespaces \- overview of Linux mount namespaces
10 .SH DESCRIPTION
11 For an overview of namespaces, see
12 .BR namespaces (7).
13 .PP
14 Mount namespaces provide isolation of the list of mounts seen
15 by the processes in each namespace instance.
16 Thus, the processes in each of the mount namespace instances
17 will see distinct single-directory hierarchies.
18 .PP
19 The views provided by the
20 .IR /proc/ pid /mounts ,
21 .IR /proc/ pid /mountinfo ,
22 and
23 .IR /proc/ pid /mountstats
24 files (all described in
25 .BR proc (5))
26 correspond to the mount namespace in which the process with the PID
27 .I pid
28 resides.
29 (All of the processes that reside in the same mount namespace
30 will see the same view in these files.)
31 .PP
32 A new mount namespace is created using either
33 .BR clone (2)
34 or
35 .BR unshare (2)
36 with the
37 .B CLONE_NEWNS
38 flag.
39 When a new mount namespace is created,
40 its mount list is initialized as follows:
41 .IP \[bu] 3
42 If the namespace is created using
43 .BR clone (2),
44 the mount list of the child's namespace is a copy
45 of the mount list in the parent process's mount namespace.
46 .IP \[bu]
47 If the namespace is created using
48 .BR unshare (2),
49 the mount list of the new namespace is a copy of
50 the mount list in the caller's previous mount namespace.
51 .PP
52 Subsequent modifications to the mount list
53 .RB ( mount (2)
54 and
55 .BR umount (2))
56 in either mount namespace will not (by default) affect the
57 mount list seen in the other namespace
58 (but see the following discussion of shared subtrees).
59 .\"
60 .SH SHARED SUBTREES
61 After the implementation of mount namespaces was completed,
62 experience showed that the isolation that they provided was,
63 in some cases, too great.
64 For example, in order to make a newly loaded optical disk
65 available in all mount namespaces,
66 a mount operation was required in each namespace.
67 For this use case, and others,
68 the shared subtree feature was introduced in Linux 2.6.15.
69 This feature allows for automatic, controlled propagation of
70 .BR mount (2)
71 and
72 .BR umount (2)
73 .I events
74 between namespaces
75 (or, more precisely, between the mounts that are members of a
76 .I peer group
77 that are propagating events to one another).
78 .PP
79 Each mount is marked (via
80 .BR mount (2))
81 as having one of the following
82 .IR "propagation types" :
83 .TP
84 .B MS_SHARED
85 This mount shares events with members of a peer group.
86 .BR mount (2)
87 and
88 .BR umount (2)
89 events immediately under this mount will propagate
90 to the other mounts that are members of the peer group.
91 .I Propagation
92 here means that the same
93 .BR mount (2)
94 or
95 .BR umount (2)
96 will automatically occur
97 under all of the other mounts in the peer group.
98 Conversely,
99 .BR mount (2)
100 and
101 .BR umount (2)
102 events that take place under
103 peer mounts will propagate to this mount.
104 .TP
105 .B MS_PRIVATE
106 This mount is private; it does not have a peer group.
107 .BR mount (2)
108 and
109 .BR umount (2)
110 events do not propagate into or out of this mount.
111 .TP
112 .B MS_SLAVE
113 .BR mount (2)
114 and
115 .BR umount (2)
116 events propagate into this mount from
117 a (master) shared peer group.
118 .BR mount (2)
119 and
120 .BR umount (2)
121 events under this mount do not propagate to any peer.
122 .IP
123 Note that a mount can be the slave of another peer group
124 while at the same time sharing
125 .BR mount (2)
126 and
127 .BR umount (2)
128 events
129 with a peer group of which it is a member.
130 (More precisely, one peer group can be the slave of another peer group.)
131 .TP
132 .B MS_UNBINDABLE
133 This is like a private mount,
134 and in addition this mount can't be bind mounted.
135 Attempts to bind mount this mount
136 .RB ( mount (2)
137 with the
138 .B MS_BIND
139 flag) will fail.
140 .IP
141 When a recursive bind mount
142 .RB ( mount (2)
143 with the
144 .B MS_BIND
145 and
146 .B MS_REC
147 flags) is performed on a directory subtree,
148 any bind mounts within the subtree are automatically pruned
149 (i.e., not replicated)
150 when replicating that subtree to produce the target subtree.
151 .PP
152 For a discussion of the propagation type assigned to a new mount,
153 see NOTES.
154 .PP
155 The propagation type is a per-mount-point setting;
156 some mounts may be marked as shared
157 (with each shared mount being a member of a distinct peer group),
158 while others are private
159 (or slaved or unbindable).
160 .PP
161 Note that a mount's propagation type determines whether
162 .BR mount (2)
163 and
164 .BR umount (2)
165 of mounts
166 .I immediately under
167 the mount are propagated.
168 Thus, the propagation type does not affect propagation of events for
169 grandchildren and further removed descendant mounts.
170 What happens if the mount itself is unmounted is determined by
171 the propagation type that is in effect for the
172 .I parent
173 of the mount.
174 .PP
175 Members are added to a
176 .I peer group
177 when a mount is marked as shared and either:
178 .IP (a) 5
179 the mount is replicated during the creation of a new mount namespace; or
180 .IP (b)
181 a new bind mount is created from the mount.
182 .PP
183 In both of these cases, the new mount joins the peer group
184 of which the existing mount is a member.
185 .PP
186 A new peer group is also created when a child mount is created under
187 an existing mount that is marked as shared.
188 In this case, the new child mount is also marked as shared and
189 the resulting peer group consists of all the mounts
190 that are replicated under the peers of parent mounts.
191 .PP
192 A mount ceases to be a member of a peer group when either
193 the mount is explicitly unmounted,
194 or when the mount is implicitly unmounted because a mount namespace is removed
195 (because it has no more member processes).
196 .PP
197 The propagation type of the mounts in a mount namespace
198 can be discovered via the "optional fields" exposed in
199 .IR /proc/ pid /mountinfo .
200 (See
201 .BR proc (5)
202 for details of this file.)
203 The following tags can appear in the optional fields
204 for a record in that file:
205 .TP
206 .I shared:X
207 This mount is shared in peer group
208 .IR X .
209 Each peer group has a unique ID that is automatically
210 generated by the kernel,
211 and all mounts in the same peer group will show the same ID.
212 (These IDs are assigned starting from the value 1,
213 and may be recycled when a peer group ceases to have any members.)
214 .TP
215 .I master:X
216 This mount is a slave to shared peer group
217 .IR X .
218 .TP
219 .IR propagate_from:X " (since Linux 2.6.26)"
220 .\" commit 97e7e0f71d6d948c25f11f0a33878d9356d9579e
221 This mount is a slave and receives propagation from shared peer group
222 .IR X .
223 This tag will always appear in conjunction with a
224 .I master:X
225 tag.
226 Here,
227 .I X
228 is the closest dominant peer group under the process's root directory.
229 If
230 .I X
231 is the immediate master of the mount,
232 or if there is no dominant peer group under the same root,
233 then only the
234 .I master:X
235 field is present and not the
236 .I propagate_from:X
237 field.
238 For further details, see below.
239 .TP
240 .I unbindable
241 This is an unbindable mount.
242 .PP
243 If none of the above tags is present, then this is a private mount.
244 .SS MS_SHARED and MS_PRIVATE example
245 Suppose that on a terminal in the initial mount namespace,
246 we mark one mount as shared and another as private,
247 and then view the mounts in
248 .IR /proc/self/mountinfo :
249 .PP
250 .in +4n
251 .EX
252 sh1# \fBmount \-\-make\-shared /mntS\fP
253 sh1# \fBmount \-\-make\-private /mntP\fP
254 sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
255 77 61 8:17 / /mntS rw,relatime shared:1
256 83 61 8:15 / /mntP rw,relatime
257 .EE
258 .in
259 .PP
260 From the
261 .I /proc/self/mountinfo
262 output, we see that
263 .I /mntS
264 is a shared mount in peer group 1, and that
265 .I /mntP
266 has no optional tags, indicating that it is a private mount.
267 The first two fields in each record in this file are the unique
268 ID for this mount, and the mount ID of the parent mount.
269 We can further inspect this file to see that the parent mount of
270 .I /mntS
271 and
272 .I /mntP
273 is the root directory,
274 .IR / ,
275 which is mounted as private:
276 .PP
277 .in +4n
278 .EX
279 sh1# \fBcat /proc/self/mountinfo | awk \[aq]$1 == 61\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
280 61 0 8:2 / / rw,relatime
281 .EE
282 .in
283 .PP
284 On a second terminal,
285 we create a new mount namespace where we run a second shell
286 and inspect the mounts:
287 .PP
288 .in +4n
289 .EX
290 $ \fBPS1=\[aq]sh2# \[aq] sudo unshare \-m \-\-propagation unchanged sh\fP
291 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
292 222 145 8:17 / /mntS rw,relatime shared:1
293 225 145 8:15 / /mntP rw,relatime
294 .EE
295 .in
296 .PP
297 The new mount namespace received a copy of the initial mount namespace's
298 mounts.
299 These new mounts maintain the same propagation types,
300 but have unique mount IDs.
301 (The
302 .I \-\-propagation\~unchanged
303 option prevents
304 .BR unshare (1)
305 from marking all mounts as private when creating a new mount namespace,
306 .\" Since util-linux 2.27
307 which it does by default.)
308 .PP
309 In the second terminal, we then create submounts under each of
310 .I /mntS
311 and
312 .I /mntP
313 and inspect the set-up:
314 .PP
315 .in +4n
316 .EX
317 sh2# \fBmkdir /mntS/a\fP
318 sh2# \fBmount /dev/sdb6 /mntS/a\fP
319 sh2# \fBmkdir /mntP/b\fP
320 sh2# \fBmount /dev/sdb7 /mntP/b\fP
321 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
322 222 145 8:17 / /mntS rw,relatime shared:1
323 225 145 8:15 / /mntP rw,relatime
324 178 222 8:22 / /mntS/a rw,relatime shared:2
325 230 225 8:23 / /mntP/b rw,relatime
326 .EE
327 .in
328 .PP
329 From the above, it can be seen that
330 .I /mntS/a
331 was created as shared (inheriting this setting from its parent mount) and
332 .I /mntP/b
333 was created as a private mount.
334 .PP
335 Returning to the first terminal and inspecting the set-up,
336 we see that the new mount created under the shared mount
337 .I /mntS
338 propagated to its peer mount (in the initial mount namespace),
339 but the new mount created under the private mount
340 .I /mntP
341 did not propagate:
342 .PP
343 .in +4n
344 .EX
345 sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
346 77 61 8:17 / /mntS rw,relatime shared:1
347 83 61 8:15 / /mntP rw,relatime
348 179 77 8:22 / /mntS/a rw,relatime shared:2
349 .EE
350 .in
351 .\"
352 .SS MS_SLAVE example
353 Making a mount a slave allows it to receive propagated
354 .BR mount (2)
355 and
356 .BR umount (2)
357 events from a master shared peer group,
358 while preventing it from propagating events to that master.
359 This is useful if we want to (say) receive a mount event when
360 an optical disk is mounted in the master shared peer group
361 (in another mount namespace),
362 but want to prevent
363 .BR mount (2)
364 and
365 .BR umount (2)
366 events under the slave mount
367 from having side effects in other namespaces.
368 .PP
369 We can demonstrate the effect of slaving by first marking
370 two mounts as shared in the initial mount namespace:
371 .PP
372 .in +4n
373 .EX
374 sh1# \fBmount \-\-make\-shared /mntX\fP
375 sh1# \fBmount \-\-make\-shared /mntY\fP
376 sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
377 132 83 8:23 / /mntX rw,relatime shared:1
378 133 83 8:22 / /mntY rw,relatime shared:2
379 .EE
380 .in
381 .PP
382 On a second terminal,
383 we create a new mount namespace and inspect the mounts:
384 .PP
385 .in +4n
386 .EX
387 sh2# \fBunshare \-m \-\-propagation unchanged sh\fP
388 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
389 168 167 8:23 / /mntX rw,relatime shared:1
390 169 167 8:22 / /mntY rw,relatime shared:2
391 .EE
392 .in
393 .PP
394 In the new mount namespace, we then mark one of the mounts as a slave:
395 .PP
396 .in +4n
397 .EX
398 sh2# \fBmount \-\-make\-slave /mntY\fP
399 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
400 168 167 8:23 / /mntX rw,relatime shared:1
401 169 167 8:22 / /mntY rw,relatime master:2
402 .EE
403 .in
404 .PP
405 From the above output, we see that
406 .I /mntY
407 is now a slave mount that is receiving propagation events from
408 the shared peer group with the ID 2.
409 .PP
410 Continuing in the new namespace, we create submounts under each of
411 .I /mntX
412 and
413 .IR /mntY :
414 .PP
415 .in +4n
416 .EX
417 sh2# \fBmkdir /mntX/a\fP
418 sh2# \fBmount /dev/sda3 /mntX/a\fP
419 sh2# \fBmkdir /mntY/b\fP
420 sh2# \fBmount /dev/sda5 /mntY/b\fP
421 .EE
422 .in
423 .PP
424 When we inspect the state of the mounts in the new mount namespace,
425 we see that
426 .I /mntX/a
427 was created as a new shared mount
428 (inheriting the "shared" setting from its parent mount) and
429 .I /mntY/b
430 was created as a private mount:
431 .PP
432 .in +4n
433 .EX
434 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
435 168 167 8:23 / /mntX rw,relatime shared:1
436 169 167 8:22 / /mntY rw,relatime master:2
437 173 168 8:3 / /mntX/a rw,relatime shared:3
438 175 169 8:5 / /mntY/b rw,relatime
439 .EE
440 .in
441 .PP
442 Returning to the first terminal (in the initial mount namespace),
443 we see that the mount
444 .I /mntX/a
445 propagated to the peer (the shared
446 .IR /mntX ),
447 but the mount
448 .I /mntY/b
449 was not propagated:
450 .PP
451 .in +4n
452 .EX
453 sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
454 132 83 8:23 / /mntX rw,relatime shared:1
455 133 83 8:22 / /mntY rw,relatime shared:2
456 174 132 8:3 / /mntX/a rw,relatime shared:3
457 .EE
458 .in
459 .PP
460 Now we create a new mount under
461 .I /mntY
462 in the first shell:
463 .PP
464 .in +4n
465 .EX
466 sh1# \fBmkdir /mntY/c\fP
467 sh1# \fBmount /dev/sda1 /mntY/c\fP
468 sh1# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
469 132 83 8:23 / /mntX rw,relatime shared:1
470 133 83 8:22 / /mntY rw,relatime shared:2
471 174 132 8:3 / /mntX/a rw,relatime shared:3
472 178 133 8:1 / /mntY/c rw,relatime shared:4
473 .EE
474 .in
475 .PP
476 When we examine the mounts in the second mount namespace,
477 we see that in this case the new mount has been propagated
478 to the slave mount,
479 and that the new mount is itself a slave mount (to peer group 4):
480 .PP
481 .in +4n
482 .EX
483 sh2# \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
484 168 167 8:23 / /mntX rw,relatime shared:1
485 169 167 8:22 / /mntY rw,relatime master:2
486 173 168 8:3 / /mntX/a rw,relatime shared:3
487 175 169 8:5 / /mntY/b rw,relatime
488 179 169 8:1 / /mntY/c rw,relatime master:4
489 .EE
490 .in
491 .\"
492 .SS MS_UNBINDABLE example
493 One of the primary purposes of unbindable mounts is to avoid
494 the "mount explosion" problem when repeatedly performing bind mounts
495 of a higher-level subtree at a lower-level mount.
496 The problem is illustrated by the following shell session.
497 .PP
498 Suppose we have a system with the following mounts:
499 .PP
500 .in +4n
501 .EX
502 # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP
503 /dev/sda1 on /
504 /dev/sdb6 on /mntX
505 /dev/sdb7 on /mntY
506 .EE
507 .in
508 .PP
509 Suppose furthermore that we wish to recursively bind mount
510 the root directory under several users' home directories.
511 We do this for the first user, and inspect the mounts:
512 .PP
513 .in +4n
514 .EX
515 # \fBmount \-\-rbind / /home/cecilia/\fP
516 # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP
517 /dev/sda1 on /
518 /dev/sdb6 on /mntX
519 /dev/sdb7 on /mntY
520 /dev/sda1 on /home/cecilia
521 /dev/sdb6 on /home/cecilia/mntX
522 /dev/sdb7 on /home/cecilia/mntY
523 .EE
524 .in
525 .PP
526 When we repeat this operation for the second user,
527 we start to see the explosion problem:
528 .PP
529 .in +4n
530 .EX
531 # \fBmount \-\-rbind / /home/henry\fP
532 # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP
533 /dev/sda1 on /
534 /dev/sdb6 on /mntX
535 /dev/sdb7 on /mntY
536 /dev/sda1 on /home/cecilia
537 /dev/sdb6 on /home/cecilia/mntX
538 /dev/sdb7 on /home/cecilia/mntY
539 /dev/sda1 on /home/henry
540 /dev/sdb6 on /home/henry/mntX
541 /dev/sdb7 on /home/henry/mntY
542 /dev/sda1 on /home/henry/home/cecilia
543 /dev/sdb6 on /home/henry/home/cecilia/mntX
544 /dev/sdb7 on /home/henry/home/cecilia/mntY
545 .EE
546 .in
547 .PP
548 Under
549 .IR /home/henry ,
550 we have not only recursively added the
551 .I /mntX
552 and
553 .I /mntY
554 mounts, but also the recursive mounts of those directories under
555 .I /home/cecilia
556 that were created in the previous step.
557 Upon repeating the step for a third user,
558 it becomes obvious that the explosion is exponential in nature:
559 .PP
560 .in +4n
561 .EX
562 # \fBmount \-\-rbind / /home/otto\fP
563 # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP
564 /dev/sda1 on /
565 /dev/sdb6 on /mntX
566 /dev/sdb7 on /mntY
567 /dev/sda1 on /home/cecilia
568 /dev/sdb6 on /home/cecilia/mntX
569 /dev/sdb7 on /home/cecilia/mntY
570 /dev/sda1 on /home/henry
571 /dev/sdb6 on /home/henry/mntX
572 /dev/sdb7 on /home/henry/mntY
573 /dev/sda1 on /home/henry/home/cecilia
574 /dev/sdb6 on /home/henry/home/cecilia/mntX
575 /dev/sdb7 on /home/henry/home/cecilia/mntY
576 /dev/sda1 on /home/otto
577 /dev/sdb6 on /home/otto/mntX
578 /dev/sdb7 on /home/otto/mntY
579 /dev/sda1 on /home/otto/home/cecilia
580 /dev/sdb6 on /home/otto/home/cecilia/mntX
581 /dev/sdb7 on /home/otto/home/cecilia/mntY
582 /dev/sda1 on /home/otto/home/henry
583 /dev/sdb6 on /home/otto/home/henry/mntX
584 /dev/sdb7 on /home/otto/home/henry/mntY
585 /dev/sda1 on /home/otto/home/henry/home/cecilia
586 /dev/sdb6 on /home/otto/home/henry/home/cecilia/mntX
587 /dev/sdb7 on /home/otto/home/henry/home/cecilia/mntY
588 .EE
589 .in
590 .PP
591 The mount explosion problem in the above scenario can be avoided
592 by making each of the new mounts unbindable.
593 The effect of doing this is that recursive mounts of the root
594 directory will not replicate the unbindable mounts.
595 We make such a mount for the first user:
596 .PP
597 .in +4n
598 .EX
599 # \fBmount \-\-rbind \-\-make\-unbindable / /home/cecilia\fP
600 .EE
601 .in
602 .PP
603 Before going further, we show that unbindable mounts are indeed unbindable:
604 .PP
605 .in +4n
606 .EX
607 # \fBmkdir /mntZ\fP
608 # \fBmount \-\-bind /home/cecilia /mntZ\fP
609 mount: wrong fs type, bad option, bad superblock on /home/cecilia,
610 missing codepage or helper program, or other error
612 In some cases useful info is found in syslog \- try
613 dmesg | tail or so.
614 .EE
615 .in
616 .PP
617 Now we create unbindable recursive bind mounts for the other two users:
618 .PP
619 .in +4n
620 .EX
621 # \fBmount \-\-rbind \-\-make\-unbindable / /home/henry\fP
622 # \fBmount \-\-rbind \-\-make\-unbindable / /home/otto\fP
623 .EE
624 .in
625 .PP
626 Upon examining the list of mounts,
627 we see there has been no explosion of mounts,
628 because the unbindable mounts were not replicated
629 under each user's directory:
630 .PP
631 .in +4n
632 .EX
633 # \fBmount | awk \[aq]{print $1, $2, $3}\[aq]\fP
634 /dev/sda1 on /
635 /dev/sdb6 on /mntX
636 /dev/sdb7 on /mntY
637 /dev/sda1 on /home/cecilia
638 /dev/sdb6 on /home/cecilia/mntX
639 /dev/sdb7 on /home/cecilia/mntY
640 /dev/sda1 on /home/henry
641 /dev/sdb6 on /home/henry/mntX
642 /dev/sdb7 on /home/henry/mntY
643 /dev/sda1 on /home/otto
644 /dev/sdb6 on /home/otto/mntX
645 /dev/sdb7 on /home/otto/mntY
646 .EE
647 .in
648 .\"
649 .SS Propagation type transitions
650 The following table shows the effect that applying a new propagation type
651 (i.e.,
652 .IR mount\~\-\-make\-xxxx )
653 has on the existing propagation type of a mount.
654 The rows correspond to existing propagation types,
655 and the columns are the new propagation settings.
656 For reasons of space, "private" is abbreviated as "priv" and
657 "unbindable" as "unbind".
658 .TS
659 lb2 lb2 lb2 lb2 lb1
660 lb | l l l l l.
661 make-shared make-slave make-priv make-unbind
662 _
663 shared shared slave/priv [1] priv unbind
664 slave slave+shared slave [2] priv unbind
665 slave+shared slave+shared slave priv unbind
666 private shared priv [2] priv unbind
667 unbindable shared unbind [2] priv unbind
668 .TE
669 .sp 1
670 Note the following details to the table:
671 .IP [1] 4
672 If a shared mount is the only mount in its peer group,
673 making it a slave automatically makes it private.
674 .IP [2]
675 Slaving a nonshared mount has no effect on the mount.
676 .\"
677 .SS Bind (MS_BIND) semantics
678 Suppose that the following command is performed:
679 .PP
680 .in +4n
681 .EX
682 mount \-\-bind A/a B/b
683 .EE
684 .in
685 .PP
686 Here,
687 .I A
688 is the source mount,
689 .I B
690 is the destination mount,
691 .I a
692 is a subdirectory path under the mount point
693 .IR A ,
694 and
695 .I b
696 is a subdirectory path under the mount point
697 .IR B .
698 The propagation type of the resulting mount,
699 .IR B/b ,
700 depends on the propagation types of the mounts
701 .I A
702 and
703 .IR B ,
704 and is summarized in the following table.
705 .PP
706 .TS
707 lb2 lb1 lb2 lb2 lb2 lb0
708 lb2 lb1 lb2 lb2 lb2 lb0
709 lb lb | l l l l l.
710 source(A)
711 shared private slave unbind
712 _
713 dest(B) shared shared shared slave+shared invalid
714 nonshared shared private slave invalid
715 .TE
716 .sp 1
717 Note that a recursive bind of a subtree follows the same semantics
718 as for a bind operation on each mount in the subtree.
719 (Unbindable mounts are automatically pruned at the target mount point.)
720 .PP
721 For further details, see
722 .I Documentation/filesystems/sharedsubtree.rst
723 in the kernel source tree.
724 .\"
725 .SS Move (MS_MOVE) semantics
726 Suppose that the following command is performed:
727 .PP
728 .in +4n
729 .EX
730 mount \-\-move A B/b
731 .EE
732 .in
733 .PP
734 Here,
735 .I A
736 is the source mount,
737 .I B
738 is the destination mount, and
739 .I b
740 is a subdirectory path under the mount point
741 .IR B .
742 The propagation type of the resulting mount,
743 .IR B/b ,
744 depends on the propagation types of the mounts
745 .I A
746 and
747 .IR B ,
748 and is summarized in the following table.
749 .PP
750 .TS
751 lb2 lb1 lb2 lb2 lb2 lb0
752 lb2 lb1 lb2 lb2 lb2 lb0
753 lb lb | l l l l l.
754 source(A)
755 shared private slave unbind
756 _
757 dest(B) shared shared shared slave+shared invalid
758 nonshared shared private slave unbindable
759 .TE
760 .sp 1
761 Note: moving a mount that resides under a shared mount is invalid.
762 .PP
763 For further details, see
764 .I Documentation/filesystems/sharedsubtree.rst
765 in the kernel source tree.
766 .\"
767 .SS Mount semantics
768 Suppose that we use the following command to create a mount:
769 .PP
770 .in +4n
771 .EX
772 mount device B/b
773 .EE
774 .in
775 .PP
776 Here,
777 .I B
778 is the destination mount, and
779 .I b
780 is a subdirectory path under the mount point
781 .IR B .
782 The propagation type of the resulting mount,
783 .IR B/b ,
784 follows the same rules as for a bind mount,
785 where the propagation type of the source mount
786 is considered always to be private.
787 .\"
788 .SS Unmount semantics
789 Suppose that we use the following command to tear down a mount:
790 .PP
791 .in +4n
792 .EX
793 umount A
794 .EE
795 .in
796 .PP
797 Here,
798 .I A
799 is a mount on
800 .IR B/b ,
801 where
802 .I B
803 is the parent mount and
804 .I b
805 is a subdirectory path under the mount point
806 .IR B .
807 If
808 .B B
809 is shared, then all most-recently-mounted mounts at
810 .I b
811 on mounts that receive propagation from mount
812 .I B
813 and do not have submounts under them are unmounted.
814 .\"
815 .SS The /proc/ pid /mountinfo "propagate_from" tag
816 The
817 .I propagate_from:X
818 tag is shown in the optional fields of a
819 .IR /proc/ pid /mountinfo
820 record in cases where a process can't see a slave's immediate master
821 (i.e., the pathname of the master is not reachable from
822 the filesystem root directory)
823 and so cannot determine the
824 chain of propagation between the mounts it can see.
825 .PP
826 In the following example, we first create a two-link master-slave chain
827 between the mounts
828 .IR /mnt ,
829 .IR /tmp/etc ,
830 and
831 .IR /mnt/tmp/etc .
832 Then the
833 .BR chroot (1)
834 command is used to make the
835 .I /tmp/etc
836 mount point unreachable from the root directory,
837 creating a situation where the master of
838 .I /mnt/tmp/etc
839 is not reachable from the (new) root directory of the process.
840 .PP
841 First, we bind mount the root directory onto
842 .I /mnt
843 and then bind mount
844 .I /proc
845 at
846 .I /mnt/proc
847 so that after the later
848 .BR chroot (1)
849 the
850 .BR proc (5)
851 filesystem remains visible at the correct location
852 in the chroot-ed environment.
853 .PP
854 .in +4n
855 .EX
856 # \fBmkdir \-p /mnt/proc\fP
857 # \fBmount \-\-bind / /mnt\fP
858 # \fBmount \-\-bind /proc /mnt/proc\fP
859 .EE
860 .in
861 .PP
862 Next, we ensure that the
863 .I /mnt
864 mount is a shared mount in a new peer group (with no peers):
865 .PP
866 .in +4n
867 .EX
868 # \fBmount \-\-make\-private /mnt\fP # Isolate from any previous peer group
869 # \fBmount \-\-make\-shared /mnt\fP
870 # \fBcat /proc/self/mountinfo | grep \[aq]/mnt\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
871 239 61 8:2 / /mnt ... shared:102
872 248 239 0:4 / /mnt/proc ... shared:5
873 .EE
874 .in
875 .PP
876 Next, we bind mount
877 .I /mnt/etc
878 onto
879 .IR /tmp/etc :
880 .PP
881 .in +4n
882 .EX
883 # \fBmkdir \-p /tmp/etc\fP
884 # \fBmount \-\-bind /mnt/etc /tmp/etc\fP
885 # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
886 239 61 8:2 / /mnt ... shared:102
887 248 239 0:4 / /mnt/proc ... shared:5
888 267 40 8:2 /etc /tmp/etc ... shared:102
889 .EE
890 .in
891 .PP
892 Initially, these two mounts are in the same peer group,
893 but we then make the
894 .I /tmp/etc
895 a slave of
896 .IR /mnt/etc ,
897 and then make
898 .I /tmp/etc
899 shared as well,
900 so that it can propagate events to the next slave in the chain:
901 .PP
902 .in +4n
903 .EX
904 # \fBmount \-\-make\-slave /tmp/etc\fP
905 # \fBmount \-\-make\-shared /tmp/etc\fP
906 # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
907 239 61 8:2 / /mnt ... shared:102
908 248 239 0:4 / /mnt/proc ... shared:5
909 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
910 .EE
911 .in
912 .PP
913 Then we bind mount
914 .I /tmp/etc
915 onto
916 .IR /mnt/tmp/etc .
917 Again, the two mounts are initially in the same peer group,
918 but we then make
919 .I /mnt/tmp/etc
920 a slave of
921 .IR /tmp/etc :
922 .PP
923 .in +4n
924 .EX
925 # \fBmkdir \-p /mnt/tmp/etc\fP
926 # \fBmount \-\-bind /tmp/etc /mnt/tmp/etc\fP
927 # \fBmount \-\-make\-slave /mnt/tmp/etc\fP
928 # \fBcat /proc/self/mountinfo | egrep \[aq]/mnt|/tmp/\[aq] | sed \[aq]s/ \- .*//\[aq]\fP
929 239 61 8:2 / /mnt ... shared:102
930 248 239 0:4 / /mnt/proc ... shared:5
931 267 40 8:2 /etc /tmp/etc ... shared:105 master:102
932 273 239 8:2 /etc /mnt/tmp/etc ... master:105
933 .EE
934 .in
935 .PP
936 From the above, we see that
937 .I /mnt
938 is the master of the slave
939 .IR /tmp/etc ,
940 which in turn is the master of the slave
941 .IR /mnt/tmp/etc .
942 .PP
943 We then
944 .BR chroot (1)
945 to the
946 .I /mnt
947 directory, which renders the mount with ID 267 unreachable
948 from the (new) root directory:
949 .PP
950 .in +4n
951 .EX
952 # \fBchroot /mnt\fP
953 .EE
954 .in
955 .PP
956 When we examine the state of the mounts inside the chroot-ed environment,
957 we see the following:
958 .PP
959 .in +4n
960 .EX
961 # \fBcat /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP
962 239 61 8:2 / / ... shared:102
963 248 239 0:4 / /proc ... shared:5
964 273 239 8:2 /etc /tmp/etc ... master:105 propagate_from:102
965 .EE
966 .in
967 .PP
968 Above, we see that the mount with ID 273
969 is a slave whose master is the peer group 105.
970 The mount point for that master is unreachable, and so a
971 .I propagate_from
972 tag is displayed, indicating that the closest dominant peer group
973 (i.e., the nearest reachable mount in the slave chain)
974 is the peer group with the ID 102 (corresponding to the
975 .I /mnt
976 mount point before the
977 .BR chroot (1)
978 was performed).
979 .\"
980 .SH VERSIONS
981 Mount namespaces first appeared in Linux 2.4.19.
982 .SH STANDARDS
983 Namespaces are a Linux-specific feature.
984 .\"
985 .SH NOTES
986 The propagation type assigned to a new mount depends
987 on the propagation type of the parent mount.
988 If the mount has a parent (i.e., it is a non-root mount
989 point) and the propagation type of the parent is
990 .BR MS_SHARED ,
991 then the propagation type of the new mount is also
992 .BR MS_SHARED .
993 Otherwise, the propagation type of the new mount is
994 .BR MS_PRIVATE .
995 .PP
996 Notwithstanding the fact that the default propagation type
997 for new mount is in many cases
998 .BR MS_PRIVATE ,
999 .B MS_SHARED
1000 is typically more useful.
1001 For this reason,
1002 .BR systemd (1)
1003 automatically remounts all mounts as
1004 .B MS_SHARED
1005 on system startup.
1006 Thus, on most modern systems, the default propagation type is in practice
1007 .BR MS_SHARED .
1008 .PP
1009 Since, when one uses
1010 .BR unshare (1)
1011 to create a mount namespace,
1012 the goal is commonly to provide full isolation of the mounts
1013 in the new namespace,
1014 .BR unshare (1)
1015 (since
1016 .I util\-linux
1017 2.27) in turn reverses the step performed by
1018 .BR systemd (1),
1019 by making all mounts private in the new namespace.
1020 That is,
1021 .BR unshare (1)
1022 performs the equivalent of the following in the new mount namespace:
1023 .PP
1024 .in +4n
1025 .EX
1026 mount \-\-make\-rprivate /
1027 .EE
1028 .in
1029 .PP
1030 To prevent this, one can use the
1031 .I \-\-propagation\~unchanged
1032 option to
1033 .BR unshare (1).
1034 .PP
1035 An application that creates a new mount namespace directly using
1036 .BR clone (2)
1037 or
1038 .BR unshare (2)
1039 may desire to prevent propagation of mount events to other mount namespaces
1040 (as is done by
1041 .BR unshare (1)).
1042 This can be done by changing the propagation type of
1043 mounts in the new namespace to either
1044 .B MS_SLAVE
1045 or
1046 .BR MS_PRIVATE ,
1047 using a call such as the following:
1048 .PP
1049 .in +4n
1050 .EX
1051 mount(NULL, "/", MS_SLAVE | MS_REC, NULL);
1052 .EE
1053 .in
1054 .PP
1055 For a discussion of propagation types when moving mounts
1056 .RB ( MS_MOVE )
1057 and creating bind mounts
1058 .RB ( MS_BIND ),
1059 see
1060 .IR Documentation/filesystems/sharedsubtree.rst .
1061 .\"
1062 .\" ============================================================
1063 .\"
1064 .SS Restrictions on mount namespaces
1065 Note the following points with respect to mount namespaces:
1066 .IP [1] 4
1067 Each mount namespace has an owner user namespace.
1068 As explained above, when a new mount namespace is created,
1069 its mount list is initialized as a copy of the mount list
1070 of another mount namespace.
1071 If the new namespace and the namespace from which the mount list
1072 was copied are owned by different user namespaces,
1073 then the new mount namespace is considered
1074 .IR "less privileged" .
1075 .IP [2]
1076 When creating a less privileged mount namespace,
1077 shared mounts are reduced to slave mounts.
1078 This ensures that mappings performed in less
1079 privileged mount namespaces will not propagate to more privileged
1080 mount namespaces.
1081 .IP [3]
1082 Mounts that come as a single unit from a more privileged mount namespace are
1083 locked together and may not be separated in a less privileged mount
1084 namespace.
1085 (The
1086 .BR unshare (2)
1087 .B CLONE_NEWNS
1088 operation brings across all of the mounts from the original
1089 mount namespace as a single unit,
1090 and recursive mounts that propagate between
1091 mount namespaces propagate as a single unit.)
1092 .IP
1093 In this context, "may not be separated" means that the mounts
1094 are locked so that they may not be individually unmounted.
1095 Consider the following example:
1096 .IP
1097 .in +4n
1098 .EX
1099 $ \fBsudo sh\fP
1100 # \fBmount \-\-bind /dev/null /etc/shadow\fP
1101 # \fBcat /etc/shadow\fP # Produces no output
1102 .EE
1103 .in
1104 .IP
1105 The above steps, performed in a more privileged mount namespace,
1106 have created a bind mount that
1107 obscures the contents of the shadow password file,
1108 .IR /etc/shadow .
1109 For security reasons, it should not be possible to
1110 .BR umount (2)
1111 that mount in a less privileged mount namespace,
1112 since that would reveal the contents of
1113 .IR /etc/shadow .
1114 .IP
1115 Suppose we now create a new mount namespace
1116 owned by a new user namespace.
1117 The new mount namespace will inherit copies of all of the mounts
1118 from the previous mount namespace.
1119 However, those mounts will be locked because the new mount namespace
1120 is less privileged.
1121 Consequently, an attempt to
1122 .BR umount (2)
1123 the mount fails as show
1124 in the following step:
1125 .IP
1126 .in +4n
1127 .EX
1128 # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1129 \fBstrace \-o /tmp/log \e\fP
1130 \fBumount /mnt/dir\fP
1131 umount: /etc/shadow: not mounted.
1132 # \fBgrep \[aq]\[ha]umount\[aq] /tmp/log\fP
1133 umount2("/etc/shadow", 0) = \-1 EINVAL (Invalid argument)
1134 .EE
1135 .in
1136 .IP
1137 The error message from
1138 .BR mount (8)
1139 is a little confusing, but the
1140 .BR strace (1)
1141 output reveals that the underlying
1142 .BR umount2 (2)
1143 system call failed with the error
1144 .BR EINVAL ,
1145 which is the error that the kernel returns to indicate that
1146 the mount is locked.
1147 .IP
1148 Note, however, that it is possible to stack (and unstack) a
1149 mount on top of one of the inherited locked mounts in a
1150 less privileged mount namespace:
1151 .IP
1152 .in +4n
1153 .EX
1154 # \fBecho \[aq]aaaaa\[aq] > /tmp/a\fP # File to mount onto /etc/shadow
1155 # \fBunshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1156 \fBsh \-c \[aq]mount \-\-bind /tmp/a /etc/shadow; cat /etc/shadow\[aq]\fP
1157 aaaaa
1158 # \fBumount /etc/shadow\fP
1159 .EE
1160 .in
1161 .IP
1162 The final
1163 .BR umount (8)
1164 command above, which is performed in the initial mount namespace,
1165 makes the original
1166 .I /etc/shadow
1167 file once more visible in that namespace.
1168 .IP [4]
1169 Following on from point [3],
1170 note that it is possible to
1171 .BR umount (2)
1172 an entire subtree of mounts that
1173 propagated as a unit into a less privileged mount namespace,
1174 as illustrated in the following example.
1175 .IP
1176 First, we create new user and mount namespaces using
1177 .BR unshare (1).
1178 In the new mount namespace,
1179 the propagation type of all mounts is set to private.
1180 We then create a shared bind mount at
1181 .IR /mnt ,
1182 and a small hierarchy of mounts underneath that mount.
1183 .IP
1184 .in +4n
1185 .EX
1186 $ \fBPS1=\[aq]ns1# \[aq] sudo unshare \-\-user \-\-map\-root\-user \e\fP
1187 \fB\-\-mount \-\-propagation private bash\fP
1188 ns1# \fBecho $$\fP # We need the PID of this shell later
1189 778501
1190 ns1# \fBmount \-\-make\-shared \-\-bind /mnt /mnt\fP
1191 ns1# \fBmkdir /mnt/x\fP
1192 ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x\fP
1193 ns1# \fBmkdir /mnt/x/y\fP
1194 ns1# \fBmount \-\-make\-private \-t tmpfs none /mnt/x/y\fP
1195 ns1# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP
1196 986 83 8:5 /mnt /mnt rw,relatime shared:344
1197 989 986 0:56 / /mnt/x rw,relatime
1198 990 989 0:57 / /mnt/x/y rw,relatime
1199 .EE
1200 .in
1201 .IP
1202 Continuing in the same shell session,
1203 we then create a second shell in a new user namespace and a new
1204 (less privileged) mount namespace and
1205 check the state of the propagated mounts rooted at
1206 .IR /mnt .
1207 .IP
1208 .in +4n
1209 .EX
1210 ns1# \fBPS1=\[aq]ns2# \[aq] unshare \-\-user \-\-map\-root\-user \e\fP
1211 \fB\-\-mount \-\-propagation unchanged bash\fP
1212 ns2# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP
1213 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1214 1240 1239 0:56 / /mnt/x rw,relatime
1215 1241 1240 0:57 / /mnt/x/y rw,relatime
1216 .EE
1217 .in
1218 .IP
1219 Of note in the above output is that the propagation type of the mount
1220 .I /mnt
1221 has been reduced to slave, as explained in point [2].
1222 This means that submount events will propagate from the master
1223 .I /mnt
1224 in "ns1", but propagation will not occur in the opposite direction.
1225 .IP
1226 From a separate terminal window, we then use
1227 .BR nsenter (1)
1228 to enter the mount and user namespaces corresponding to "ns1".
1229 In that terminal window, we then recursively bind mount
1230 .I /mnt/x
1231 at the location
1232 .IR /mnt/ppp .
1233 .IP
1234 .in +4n
1235 .EX
1236 $ \fBPS1=\[aq]ns3# \[aq] sudo nsenter \-t 778501 \-\-user \-\-mount\fP
1237 ns3# \fBmount \-\-rbind \-\-make\-private /mnt/x /mnt/ppp\fP
1238 ns3# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP
1239 986 83 8:5 /mnt /mnt rw,relatime shared:344
1240 989 986 0:56 / /mnt/x rw,relatime
1241 990 989 0:57 / /mnt/x/y rw,relatime
1242 1242 986 0:56 / /mnt/ppp rw,relatime
1243 1243 1242 0:57 / /mnt/ppp/y rw,relatime shared:518
1244 .EE
1245 .in
1246 .IP
1247 Because the propagation type of the parent mount,
1248 .IR /mnt ,
1249 was shared, the recursive bind mount propagated a small subtree of
1250 mounts under the slave mount
1251 .I /mnt
1252 into "ns2",
1253 as can be verified by executing the following command in that shell session:
1254 .IP
1255 .in +4n
1256 .EX
1257 ns2# \fBgrep /mnt /proc/self/mountinfo | sed \[aq]s/ \- .*//\[aq]\fP
1258 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1259 1240 1239 0:56 / /mnt/x rw,relatime
1260 1241 1240 0:57 / /mnt/x/y rw,relatime
1261 1244 1239 0:56 / /mnt/ppp rw,relatime
1262 1245 1244 0:57 / /mnt/ppp/y rw,relatime master:518
1263 .EE
1264 .in
1265 .IP
1266 While it is not possible to
1267 .BR umount (2)
1268 a part of the propagated subtree
1269 .RI ( /mnt/ppp/y )
1270 in "ns2",
1271 it is possible to
1272 .BR umount (2)
1273 the entire subtree,
1274 as shown by the following commands:
1275 .IP
1276 .in +4n
1277 .EX
1278 ns2# \fBumount /mnt/ppp/y\fP
1279 umount: /mnt/ppp/y: not mounted.
1280 ns2# \fBumount \-l /mnt/ppp | sed \[aq]s/ \- .*//\[aq]\fP # Succeeds...
1281 ns2# \fBgrep /mnt /proc/self/mountinfo\fP
1282 1239 1204 8:5 /mnt /mnt rw,relatime master:344
1283 1240 1239 0:56 / /mnt/x rw,relatime
1284 1241 1240 0:57 / /mnt/x/y rw,relatime
1285 .EE
1286 .in
1287 .IP [5]
1288 The
1289 .BR mount (2)
1290 flags
1291 .BR MS_RDONLY ,
1292 .BR MS_NOSUID ,
1293 .BR MS_NOEXEC ,
1294 and the "atime" flags
1295 .RB ( MS_NOATIME ,
1296 .BR MS_NODIRATIME ,
1297 .BR MS_RELATIME )
1298 settings become locked
1299 .\" commit 9566d6742852c527bf5af38af5cbb878dad75705
1300 .\" Author: Eric W. Biederman <ebiederm@xmission.com>
1301 .\" Date: Mon Jul 28 17:26:07 2014 -0700
1302 .\"
1303 .\" mnt: Correct permission checks in do_remount
1304 .\"
1305 when propagated from a more privileged to
1306 a less privileged mount namespace,
1307 and may not be changed in the less privileged mount namespace.
1308 .IP
1309 This point is illustrated in the following example where,
1310 in a more privileged mount namespace,
1311 we create a bind mount that is marked as read-only.
1312 For security reasons,
1313 it should not be possible to make the mount writable in
1314 a less privileged mount namespace, and indeed the kernel prevents this:
1315 .IP
1316 .in +4n
1317 .EX
1318 $ \fBsudo mkdir /mnt/dir\fP
1319 $ \fBsudo mount \-\-bind \-o ro /some/path /mnt/dir\fP
1320 $ \fBsudo unshare \-\-user \-\-map\-root\-user \-\-mount \e\fP
1321 \fBmount \-o remount,rw /mnt/dir\fP
1322 mount: /mnt/dir: permission denied.
1323 .EE
1324 .in
1325 .IP [6]
1326 .\" (As of 3.18-rc1 (in Al Viro's 2014-08-30 vfs.git#for-next tree))
1327 A file or directory that is a mount point in one namespace that is not
1328 a mount point in another namespace, may be renamed, unlinked, or removed
1329 .RB ( rmdir (2))
1330 in the mount namespace in which it is not a mount point
1331 (subject to the usual permission checks).
1332 Consequently, the mount point is removed in the mount namespace
1333 where it was a mount point.
1334 .IP
1335 Previously (before Linux 3.18),
1336 .\" mtk: The change was in Linux 3.18, I think, with this commit:
1337 .\" commit 8ed936b5671bfb33d89bc60bdcc7cf0470ba52fe
1338 .\" Author: Eric W. Biederman <ebiederman@twitter.com>
1339 .\" Date: Tue Oct 1 18:33:48 2013 -0700
1340 .\"
1341 .\" vfs: Lazily remove mounts on unlinked files and directories.
1342 attempting to unlink, rename, or remove a file or directory
1343 that was a mount point in another mount namespace would result in the error
1344 .BR EBUSY .
1345 That behavior had technical problems of enforcement (e.g., for NFS)
1346 and permitted denial-of-service attacks against more privileged users
1347 (i.e., preventing individual files from being updated
1348 by bind mounting on top of them).
1349 .SH EXAMPLES
1350 See
1351 .BR pivot_root (2).
1352 .SH SEE ALSO
1353 .BR unshare (1),
1354 .BR clone (2),
1355 .BR mount (2),
1356 .BR mount_setattr (2),
1357 .BR pivot_root (2),
1358 .BR setns (2),
1359 .BR umount (2),
1360 .BR unshare (2),
1361 .BR proc (5),
1362 .BR namespaces (7),
1363 .BR user_namespaces (7),
1364 .BR findmnt (8),
1365 .BR mount (8),
1366 .BR pam_namespace (8),
1367 .BR pivot_root (8),
1368 .BR umount (8)
1369 .PP
1370 .I Documentation/filesystems/sharedsubtree.rst
1371 in the kernel source tree.