A process can enter a new Linux mount namespace and still observe a later mount created elsewhere. The namespace boundary is intact: the process has its own mount table. The new mount appears because some mounts in the two namespaces remain connected by propagation relationships.
This distinction matters in container runtimes, service sandboxes, build systems, and privileged helpers. Creating a mount namespace separates the namespace’s view of the mount table, but it does not by itself make every future mount event local. Shared-subtree state determines whether mount and unmount events cross that boundary.
The relevant states are properties of mounts, not global properties of a namespace. A single namespace can contain shared, slave, private, and unbindable mounts at the same time. Filesystem isolation therefore depends on both namespace membership and the propagation topology of the mounts inside it.
Namespace creation copies a mount topology
A new mount namespace created with clone() or unshare() begins with a mount list derived from an existing namespace. After creation, the two namespaces can modify their mount tables independently, subject to shared-subtree propagation.
That qualification is important. If a corresponding mount is shared, clones of that mount remain members of the same peer group. A mount or unmount event beneath one peer can propagate to the other peers. The namespaces are distinct, yet selected topology changes remain coupled.
This behavior solves real operational problems. A host can make a newly attached filesystem visible to dependent namespaces without issuing the same mount operation separately inside each one. The same mechanism can also violate an isolation assumption when software treats CLONE_NEWNS as equivalent to a fully disconnected filesystem view.
The security property is therefore narrower: a mount namespace separates mount-table membership, while propagation state controls event flow between related mounts.
Shared mounts create bidirectional event channels
A shared mount belongs to a peer group. Mount and unmount events beneath a shared mount propagate to other mounts in that peer group, and events from those peers can propagate back.
The relationship concerns mount topology. It does not merge process credentials, file descriptors, or namespace identities. It also does not mean that ordinary file writes are replicated by the propagation mechanism. The propagated objects are mount and unmount events at corresponding locations.
This distinction is especially significant for a privileged host and a constrained workload. If a host path and a workload path remain peers in a shared group, a mount operation performed on the workload side may propagate outward when the topology permits it. A design that expects mounts created inside the workload to remain local must break or redirect that propagation relationship.
Peer groups can extend across namespace boundaries. Inspecting only the fact that two processes have different mount namespace identifiers does not establish that mount events cannot travel between their filesystem views.
Slave mounts make propagation directional
A slave mount receives propagation events from its master peer group but does not send its own events back to that master. This creates a useful asymmetric boundary.
A sandbox may need to receive host-side mounts while keeping mounts created inside the sandbox from appearing on the host. Marking the relevant tree as slave can provide that directionality. Host events flow inward; local events do not flow back through the master relationship.
A mount can also be both slave and shared. In that state it receives events from an upstream master and can distribute events among its own peer group and downstream slaves. Propagation topology can therefore form a hierarchy rather than a simple pair of namespaces.
This is a reason to treat slave as a directional relationship, not as a synonym for isolated. It deliberately preserves one propagation path.
Private mounts cut both propagation directions
A private mount neither sends nor receives propagation events. Converting a subtree to private state is the direct choice when mount activity beneath that subtree must remain disconnected from peer propagation.
The recursive form matters for trees containing nested mounts. Changing only one mount does not automatically express the intended policy for every descendant. Runtime code commonly applies a recursive propagation change when preparing an isolated mount tree because nested mounts may otherwise retain relationships that do not match the boundary expected for the whole tree.
Private state does not provide every filesystem security property. Processes may still access the same underlying filesystem objects through paths visible in their namespaces, and normal discretionary or mandatory access controls still apply. Private propagation prevents topology events from crossing the propagation relationship; it does not create a new storage object or revoke access to an existing one.
Unbindable state also blocks bind replication
An unbindable mount has private propagation behavior and additionally cannot be used as the source of a bind mount. During a recursive bind operation, unbindable subtrees are pruned from the replicated tree.
That extra property can be useful when a mount must not be replicated into another location through bind mounting. It is distinct from ordinary private state: both stop propagation, but only unbindable state adds the bind restriction.
The distinction also shows that mount isolation has several dimensions. Event propagation controls future topology changes, while bind eligibility controls whether an existing subtree can be replicated into another mount location. A security design may need one or both properties.
User namespaces add another privilege boundary
Mount namespaces have an owning user namespace. When a mount namespace is less privileged than the namespace from which its mount list was copied, the kernel applies additional restrictions. In particular, shared mounts copied into the less-privileged mount namespace are reduced to slave mounts so that mount events created in the less-privileged namespace do not propagate back into the more-privileged namespace.
The kernel also locks together mounts that arrive as a unit from a more privileged namespace in cases described by the mount-namespace interface. This prevents a less-privileged namespace from simply unmounting selected protective mounts that were inherited from the more privileged context.
These rules strengthen the boundary, but they do not make propagation state irrelevant. Deployment policy still needs to account for which host events should enter a child namespace and which subtrees should be fully private.
Propagation policy is part of sandbox construction
A robust mount sandbox has two separate questions. The first is which mount namespace the process occupies. The second is which propagation relationships remain on the mounts visible there.
For a fully local subtree, private propagation removes event flow in both directions. For a subtree that should receive host mounts without exporting local mount events, slave propagation expresses the asymmetric policy. Shared propagation is appropriate only when bidirectional event distribution is intentional. Unbindable state adds a separate restriction against bind replication.
These choices are kernel-enforced topology rules rather than labels attached to a container concept. The effective boundary is visible in the mount graph itself. Namespace separation creates the place for an isolated filesystem view; propagation state determines which future mount events are still permitted to cross it.