Filesystem mounts in user namespaces
summary
Kernel 4.18 already allows mount FUSE from 4.18 by keeping filesystem code in userspace; the VFS now records superblock stores owning user namespace and adds a device-node restriction flag so mounts created by non-initial user namespaces can’t manufacture raw device access. Filesystem capabilities are namespaced so binaries set inside a user namespace can’t be abused by the host. Workarounds include a privileged syscall-proxy and a planned fsopen/fsconfig new mount API, while overlayfs pending upstream for unprivileged mounts.
AI-written summary · about
chapters (9)
- 0:00Introduction to namespaces
- 3:42Namespace usage and limits
- 5:20User namespace fundamentals
- 8:37UID mapping implementation
- 11:59Capabilities and ownership
- 14:47File system security risks
- 17:43Enabling mounts safely
- 20:55Filesystem robustness
- 25:08Future solutions and outlook
related talks
42mWhat's New in the User Namespace
57mNamespaces for Security
19mExtension Framework for File Systems in User space
26mDive into Apple UserFS (Userspace Filesystem)
32mBringing up FUSE mounts C/R support
47mLinux user namespaces: a blessing and a curse
01h 03mLinux Namespaces for Fun and Isolation
35mOverview and Recent Developments: Namespaces and Capabilities