From: Christian Brauner Date: Thu, 25 Jun 2026 10:40:26 +0000 (+0200) Subject: Merge patch series "ovl: support idmapped overlay mounts" X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=68f0e94b5850289c103278497457652b18c7355f;p=thirdparty%2Fkernel%2Flinux.git Merge patch series "ovl: support idmapped overlay mounts" Christian Brauner says: ovl: support idmapped overlay mounts I've been asked about this feature multiple times and had actually implemented it right when I did the initial idmapped layer support. So here's a new version of this series. This series lets the merged overlayfs mount itself be idmapped via mount_setattr(MOUNT_ATTR_IDMAP), in addition to the already supported idmapped lower and upper layers. It allows the same overlay tree to be exposed under a different ownership view, e.g. a container seeing the merged tree as 0:0 regardless of the on-disk or per-layer ids. Overlayfs already normalizes every underlying id through the relevant layer idmap when it copies attributes into the overlay inode (ovl_copyattr()), so the overlay inode's i_{u,g}id are "overlay-final" ids. The overlay mount idmap O composes on top of that pivot: caller view <--O--> overlay-final id <--layer idmap--> on-disk O is applied at the overlay-inode boundary only - permission, getattr, setattr, the ACL owner checks and inode_init_owner() - while the underlying layers keep being accessed with the mounter's credentials through their own, possibly idmapped, mounts. The mount idmap thus only changes how the caller sees the overlay inode and never widens the mounter's access to the layers: the second, mounter-credential check in ovl_permission() against the real inode stays on the layer idmap. Most paths need no change because the VFS applies O to the overlay inode before overlayfs runs (sticky/rename/unlink/create gating) or after it returns at the syscall boundary (the POSIX ACL get/set translation). Overlayfs only acts where it bypasses the generic path: getattr (it stats the real path), the setattr forward to the upper (the requested id is rebased from O into overlay-final space before being handed down), inode_init_owner() on create/tmpfile, and its own owner checks in ovl_set_acl(). FS_ALLOW_IDMAP is set last, once every operation honors O, so there is no bisection point where the mount is idmappable but an operation still ignores the idmapping. Note that fstests will be broken by this temporarily as they rely on the ability to create whiteouts for unprivileged device node creation. That can be adjusted. * patches from https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-0-7381632aa402@kernel.org: ovl: document security.capability idmapping on the xattr forward paths selftests/filesystems/overlayfs: test idmapped overlay mounts selftests/filesystems/overlayfs: fix set_layers_via_fds link error docs: document idmapped overlay mounts ovl: allow idmapping overlay mounts ovl: handle idmapped mounts in ovl_set_acl() ovl: handle idmapped mounts in ovl_getattr() ovl: handle idmapped mounts in ovl_setattr() ovl: handle idmapped mounts in ovl_permission() ovl: handle idmapped mounts in ovl_create_object() and ovl_tmpfile() Link: https://patch.msgid.link/20260615-work-idmapped-overlayfs-v1-0-7381632aa402@kernel.org Signed-off-by: Christian Brauner (Amutable) --- 68f0e94b5850289c103278497457652b18c7355f