Re: [PATCH 00/10] ovl: support idmapped overlay mounts

On Mon, Jun 15, 2026 at 3:20 PM Christian Brauner <[email protected]> wrote:
>
> 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]>
> ---

Apart from the minor comments on the test, the entire series looks good to me,
so you may add:
Reviewed-by: Amir Goldstein <[email protected]>

The problem is that my review can only assert that your changes make sense.

I am not even close to being able to prove that this is risk free.

This is the first time that we will have a combination of
FS_ALLOW_IDMAP | FS_USERNS_MOUNT with fs which is a proxy to
another fs, which to me sounds like Vulnerability Scanners heaven.

Could we maybe ask our friends in Anthropic to unleash Claude Mythos
on this work to try to beat the AI kiddies to it before we merge this work?

Sorry for my lack of faith in human kind ;)

Amir.