A mount namespace isolates the filesystem mount view available to a process group. Container processes see only the filesystem content assigned to their namespace, rather than the host filesystem. section 10.7 section 1.2
Podman creates a rootfs mount point, bind-mounts the container’s volumes onto it, and invokes the OCI runtime. The runtime uses pivot_root to make rootfs the namespace’s root, causing the host operating system’s filesystems to disappear from the container view. section 10.7
Mount namespaces form part of a layered container security boundary:
- A user namespace supplies the permissions needed for rootless Podman to create and mount filesystems. section 6.1.1 section 6.3
- Dropping CAP_SYS_ADMIN prevents processes inside the container from changing rootfs mounts to expose underlying filesystems. section 10.7
- SELinux provides an additional defense against escapes that defeat namespace isolation, including runtime vulnerabilities. section 10.7 section 10.0
Inspecting and testing the mount namespace
Compare the namespace identifiers with `ls -l /proc/self/ns/mnt` and `podman unshare ls -l /proc/self/ns/user /proc/self/ns/mnt`. A mount that requires host privilege can succeed inside both namespaces: `podman unshare bash -c "mount -o bind /tmp/testfile /etc/shadow; cat /etc/shadow"`. The result is visible through the namespaced process, not as unrestricted host filesystem access.
