[PATCH 00/10] 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.

Signed-off-by: Christian Brauner (Amutable) <[email protected]>
---
Christian Brauner (10):
      ovl: handle idmapped mounts in ovl_create_object() and ovl_tmpfile()
      ovl: handle idmapped mounts in ovl_permission()
      ovl: handle idmapped mounts in ovl_setattr()
      ovl: handle idmapped mounts in ovl_getattr()
      ovl: handle idmapped mounts in ovl_set_acl()
      ovl: allow idmapping overlay mounts
      docs: document idmapped overlay mounts
      selftests/filesystems/overlayfs: fix set_layers_via_fds link error
      selftests/filesystems/overlayfs: test idmapped overlay mounts
      ovl: document security.capability idmapping on the xattr forward paths

 Documentation/filesystems/overlayfs.rst            |  16 +
 fs/overlayfs/dir.c                                 |  16 +-
 fs/overlayfs/inode.c                               |  26 +-
 fs/overlayfs/overlayfs.h                           |   1 +
 fs/overlayfs/super.c                               |   2 +-
 fs/overlayfs/xattrs.c                              |   1 +
 .../selftests/filesystems/overlayfs/.gitignore     |   1 +
 .../selftests/filesystems/overlayfs/Makefile       |   2 +
 .../filesystems/overlayfs/idmapped_mounts.c        | 501 +++++++++++++++++++++
 .../filesystems/overlayfs/set_layers_via_fds.c     |  16 +-
 10 files changed, 560 insertions(+), 22 deletions(-)
---
base-commit: 254f49634ee16a731174d2ae34bc50bd5f45e731
change-id: 20260615-work-idmapped-overlayfs-0b05e79bd216