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

On Wed, Jun 17, 2026 at 03:56:57PM +0200, Amir Goldstein wrote:
> 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?

I would be happy if they did.

> Sorry for my lack of faith in human kind ;)

I will take this personally and I will seek in-person revenge in
September.