docs: document idmapped overlay mounts

Describe that the merged overlay mount itself can be turned into an
idmapped mount with mount_setattr(2), how the overlay mount idmapping
composes with any layer idmappings, and that the mounter's access to
the underlying layers is unaffected.

Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-7-7381632aa402@kernel.org
Reviewed-by: Amir Goldstein <amir73il@gmail.com>
Signed-off-by: Christian Brauner (Amutable) <brauner@kernel.org>
This commit is contained in:
Christian Brauner 2026-06-15 15:19:56 +02:00
parent adedb6a00a
commit 18a76ce66f
No known key found for this signature in database
GPG Key ID: 91C61BC06578DCA2

View File

@ -347,6 +347,22 @@ The resulting access permissions should be the same. The difference is in
the time of copy (on-demand vs. up-front).
Idmapped mounts
---------------
The overlay mount itself can be turned into an idmapped mount by applying an
idmapping to it with mount_setattr(2) and MOUNT_ATTR_IDMAP, just like for
other filesystems that support idmapped mounts.
The mount idmapping only changes how ownership and permissions of the overlay
inodes are presented to and interpreted for the caller. It does not change
how overlayfs accesses the underlying layers: those are still accessed with
the stashed mounter's credentials through their own mounts, which may
themselves be idmapped. The overlay mount idmapping and any layer idmapping
compose, an underlying id is first mapped according to the relevant layer
idmapping and then according to the overlay mount idmapping.
Multiple lower layers
---------------------