A process on a Linux host gets its own mount namespace, yet it is not automatically a sealed copy of the host's mount table. Explain mount propagation — shared, private, slave and unbindable — and which type gives one-way visibility from the host into the namespace.

## Why propagation exists at all When `CLONE_NEWNS` gives a process a new mount namespace, the kernel copies the current mount table into it. If that were the end of the story, the copy would be frozen: plug in a disk on the host after the copy was taken and the isolated process could never see it, which breaks any workflow where a supervisor wants to hand a filesystem to an already-running sandbox. Shared subtrees solve this. Each mount belongs to a *peer group*, and its propagation type determines how mount and unmount events move between members of that group. The types are per-mount, not per-namespace, so one namespace can be shared in one subtree and private in another. ## The four types **shared (`MS_SHARED`)** — the mount is a member of a peer group and events propagate in **both** directions. Mount something under it in one namespace and the mount appears at the corresponding point in every peer. This is the default on a systemd host for `/`, deliberately, so that things like removable media and network mounts reach services that were started earlier. **private (`MS_PRIVATE`)** — the mount belongs to no peer group. Nothing propagates in, nothing propagates out. This is the safe default for a sandbox that must not leak, and it is what `unshare --mount` applies by default when it creates the namespace. **slave (`MS_SLAVE`)** — the mount has a master peer group and receives events from it, but its own mounts and unmounts do not travel back. This is the asymmetric case: the host can hand filesystems in, and the namespace cannot push anything out. It is the setting sandbox tooling reaches for when it bind-mounts a host directory into an isolated tree. **unbindable (`MS_UNBINDABLE`)** — private, and additionally the mount may not be used as the *source* of a bind mount. Its purpose is to prevent the pathological growth you get when you recursively bind-mount a tree that contains a shared mount of itself; marking such points unbindable stops the recursion. Each type has a recursive form applied with the `r` variants, which set the type on the mount and everything under it. ## Reading the current state The authoritative source is `/proc/self/mountinfo`. Each line carries optional fields before the separator: ```bash grep ' / ' /proc/self/mountinfo # 25 1 259:2 / / rw,relatime shared:1 - ext4 /dev/nvme0n1p2 rw ``` `shared:1` means this mount is in peer group 1. A line carrying `master:1` and no `shared:` tag is a **slave** of peer group 1. A line carrying both is a slave that is itself shared with further peers. A line with neither is private. `unbindable` appears as its own tag. The friendlier view is `findmnt -o TARGET,PROPAGATION`, which prints the type per mount point directly. ## The failure modes you get asked about **"My container-style sandbox leaked a mount onto the host."** The tree was left shared. Because the copy inherits propagation, a mount made inside a shared subtree propagates straight back out. Marking the tree `rslave` or `rprivate` after creating the namespace is the fix. **"A filesystem mounted on the host after startup is invisible inside."** The tree was made fully private. Nothing propagates in. If the sandbox is supposed to see later host mounts under a particular path, that path needs to be slave rather than private. **"Unmounting on the host did not free the device."** A propagated copy of the mount still exists in another namespace, holding a reference. Until every peer's copy is gone, the filesystem stays busy — which is also why an ordinary `umount` on the host can appear to succeed while the block device is still in use. ## Setting it deliberately ```bash # make a subtree strictly one-way: host -> namespace mount --make-rslave /mnt/hostdata # fully isolate a subtree in both directions mount --make-rprivate /srv/sandbox ``` The order matters: propagation is set on mounts as they exist now, so a sandbox typically creates its mount namespace, immediately re-marks its whole tree, and only then performs the mounts it wants to keep to itself. Doing it the other way round means the first mounts have already propagated. ## The interview framing The question underneath all of this is whether you understand that a mount namespace is a *copy with a relationship*, not a snapshot. Someone who says "a new mount namespace is completely isolated" has not hit the leak, and someone who says "it is a frozen copy" has not hit the invisible-disk case. Both symptoms come from the same mechanism seen from opposite ends.