Mount propagation: isolate topology as well as pathnames

A mount namespace provides a view of a mount tree. Creating one begins with a copy of an existing mount layout, including relevant propagation relationships; it does not deep-copy filesystem contents. A shared mount belongs to a peer group whose mount and unmount events can propagate to peers. A slave receives relevant events from its master but does not send them back upstream. A mount can participate in more nuanced shared-and-slave relationships, so classify the actual mount object instead of assuming four labels describe every topology completely.

Private mounts do not participate in that shared event propagation. Unbindable mounts add restrictions on bind replication. These properties concern mount topology changes, such as a new filesystem appearing beneath a mount, not ordinary writes to files in a shared backing filesystem. Making a mount private does not copy its data or make existing file contents confidential. Conversely, two isolated mount trees can still expose the same underlying writable directory through bind mounts. A correct explanation keeps visibility of names, topology, and data access separate.

A bind mount and a recursive bind mount differ in whether existing subordinate mounts are replicated. Similarly, changing one mount's propagation state is different from recursively changing its descendants. A runtime that intends an isolated root subtree must account for every relevant nested mount, not just apply a private label to the top and assume children changed too. Inspect mountinfo optional fields such as shared and master identifiers to reconstruct the relationships visible from the target process's mount namespace.

The process root and working directory are separate references. chroot changes pathname resolution but is not a complete security boundary against privileged processes or inherited descriptors. Runtime root setup commonly uses pivot_root or an equivalent supported mechanism with careful cleanup of old-root references. Open file descriptors, current directories, and bind mounts can preserve access to objects outside the intended path tree. A read-only root mount also does not automatically make every separately mounted writable volume read-only; inspect the effective mount attributes at each destination.

Build a small table listing mount IDs, parent IDs, namespace identity, propagation group, source, target, and read/write attributes. Then predict where one test mount event should appear and verify that prediction in a disposable controlled environment. Unexpected propagation often comes from an inherited shared relationship or a nested mount omitted by a nonrecursive operation. Testing one pathname says little about another subtree with a different relationship. Preserve the exact runtime version and configuration when comparing results, because defaults can differ.

The probability lab illustrates the limited evidence from sampling test paths. Reset, explicitly set p=0.25 and n=4, interpret success as detecting a hypothetical propagation error, predict the zero-success bar, then Play or Step. For a separate sample-size comparison Reset and explicitly set p=0.25 and n=8. This assumes independent equal-probability tests; real mount checks can be correlated. The diagram contains no namespaces, peers, slaves, or mount operations, so a passing sample cannot replace the topology audit.