CAP_SYS_ADMIN requirement for mounts inside user namespaces – inconsistent behavior

CAP_SYS_ADMIN requirement for mounts inside user namespaces – inconsistent behavior

Linux capabilities allow fine‑grained privilege control, yet the boundary of when CAP_SYS_ADMIN is required to perform mount operations inside a user namespace remains unclear. Kernel releases 5.10 through 6.1, along with distribution‑specific patches, show varying behavior for bind, loop, and other mount types.

The goal is to delineate the exact conditions under which a process in a new user namespace must possess CAP_SYS_ADMIN to successfully mount a filesystem, and to understand how different kernel versions and distro patches affect this requirement.

Key constraints include:

• Kernel version differences (e.g., 5.15 vs 6.1)
• Distro patches that may alter namespace mount semantics
• Potential security implications of granting CAP_SYS_ADMIN in a user namespace

Unresolved questions:

1. What is the precise set of mount operations that still require CAP_SYS_ADMIN inside a user namespace across recent kernel releases?
2. How do distribution‑specific patches modify the CAP_SYS_ADMIN requirement for bind or loop mounts?
3. Can a minimal capability set be defined that allows all non‑privileged mounts without granting CAP_SYS_ADMIN?