Idmapped Mounts Remap File Ownership Without Rewriting Inodes
A container needs read-write access to a directory whose files carry host ownership values that do not line up with the container’s user namespace. Recursively changing ownership can make the directory usable, but it also mutates persistent inode metadata and can disrupt every other view of the same filesystem. Linux idmapped mounts provide a narrower mechanism: one mount can apply a different identity mapping while the stored ownership remains intact.
The security effect is local to the mount. The same inode can be reached through another mount with a different ownership view, so a numeric UID shown through one path is not a universal property of the inode’s effective access context. Permission decisions involving an idmapped mount incorporate its mapping, subject to filesystem support and the caller’s credentials.
The mount carries an identity translation layer
An idmapped mount is associated with an idmapping derived from a user namespace. The VFS uses that mapping when ownership is presented through the mount and when relevant permission operations translate identities between the caller and filesystem domains. The filesystem still retains its stored ownership values.
This separates persistent inode identity from mount-relative identity. If a file is stored with an owner that maps to UID 0 through a particular mount, processes using that mount can see the mapped owner while another mount can expose a different numeric value for the same inode. No recursive chown is required merely to create that alternate view.
The distinction also means that audit or policy code should not treat a displayed UID as sufficient evidence of the raw filesystem owner. The path and mount through which an object was reached are part of the identity context.
mount_setattr binds the mapping to a mount object
Linux exposes idmapped-mount configuration through mount_setattr() with MOUNT_ATTR_IDMAP. The userns_fd member identifies the user namespace whose mapping is to be associated with the mount.
A common construction uses a detached mount cloned with open_tree(..., OPEN_TREE_CLONE), applies the idmapping while that mount is detached, then attaches it with move_mount(). This file-descriptor-based sequence keeps the mount object explicit while its attributes are prepared.
The operation is constrained rather than universally applicable. Kernel and filesystem support are required, privilege checks apply, and the rules for applying or replacing an idmapping depend on the mount state and kernel API semantics. Software must treat failure as a real deployment condition rather than assuming every filesystem accepts MOUNT_ATTR_IDMAP.
Permission checks use the mapped ownership context
The mapping is not cosmetic output formatting. VFS operations that support idmapped mounts use mount-relative identity values for ownership-sensitive checks and metadata operations. That permits a process identity to line up with file ownership through the mount even when the raw inode IDs belong to another numeric range.
This property is useful for isolated workloads whose user namespaces use non-overlapping host ID ranges. A filesystem tree can be exposed to such a workload with a compatible mount mapping instead of rewriting every inode to the workload’s host-side IDs.
The mapping does not grant arbitrary authority outside normal access-control rules. Mode bits, ACL processing, capabilities, filesystem behavior, caller credentials, and other active security mechanisms still participate. An idmapped mount changes the identity translation used by supported VFS paths; it is not a general bypass for discretionary or mandatory access controls.
Multiple mounts can expose different ownership views
Because the mapping belongs to a mount rather than to the inode, two mounts can expose the same underlying objects with different identity translations. This is the central isolation property and also an operational constraint.
Tools that compare ownership across paths may report different numeric identities even when both paths resolve to the same underlying inode. Backup software, policy engines, file-sharing services, and diagnostic tooling therefore need to distinguish raw filesystem ownership from the ownership visible through a particular mount when that distinction affects their decisions.
A process that receives a file descriptor opened through an idmapped mount also should not reconstruct its security model from a pathname observed elsewhere. File descriptors preserve references to kernel objects and mount context in ways that pathname-only reasoning can obscure.
Filesystem support defines the deployment boundary
Idmapped mounts require cooperation from the relevant filesystem and VFS paths. Support has expanded across Linux filesystems, but support for one filesystem or kernel release does not imply identical behavior everywhere. Stacked filesystems add another layer because their own mount mapping can interact with mappings on underlying layers according to filesystem-specific semantics.
Overlayfs illustrates that distinction: an idmapping on the overlay mount affects ownership presentation and interpretation at the overlay view, while access to underlying layers follows overlayfs rules and any mappings associated with those layer mounts. Treating all layers as one interchangeable identity domain can produce incorrect access assumptions.
The durable security model is therefore mount-relative. Stored inode ownership remains one input, the mount idmapping supplies an identity translation, and the active VFS and filesystem rules determine the resulting access checks. That boundary permits localized ownership views without converting a temporary namespace requirement into a persistent metadata rewrite.