Re: [RFC PATCH] fs: allow opening overlayfs/erofs layers through O_ALT

On Wed, Jul 22, 2026 at 09:29:22AM -0700, Andy Lutomirski wrote:
> On Wed, Jul 22, 2026 at 9:06 AM Christian Brauner <[email protected]> wrote:
> 
> > Like I said before: I'm fine with an API where we can use open_tree() to
> > see through into underlying layers, and given the right permission pull
> > a mount out of it. That is a narrow, checkable primitive and it needs
> > none of this. No new open flag, no second ->show_options, no metafs, no
> > mnt_devname surgery. That part we can potentially do.
> 
> What, exactly, do you mean as the distinction between "[seeing]
> through into underlying layers" and "[pulling] a mount out of it".  I
> have a guess, but I'm not convinced that my guess is right.

Two operations that the proposal merges into one.

Seeing through is introspection. You want to know that the overlay has
three lower layers, that lower[0] is an erofs, which image it came
from, what its fsid is. That's information. It should come back as
data, from statmount(), the way every other mount property does. It
hands out no new reachability, so it needs no new permission model, and
it's roughly what Amir is arguing for in this thread. I think he's
right that this half covers most of the actual use case.

Pulling a mount out is acquisition. You want a usable mount for that
lower layer. That's a capability transfer and the layer is an internal
mount with no mountpoint anywhere, and afterwards you can walk it. That
needs to be an explicit, privileged operation with a single call site,
and what it hands back should be a detached mount fd, which is exactly
what open_tree(OPEN_TREE_CLONE) already gives you. Same lifetime rules,
same move_mount() to attach it, nothing new to reason about.

The reason to keep them apart is that they have entirely different
security answers, and merging them into one path walk is precisely what
forces "whose creds" to be answered per node instead of once. Split,
the introspection half never has to ask, and the acquisition half
answers it at the top, before anything is reachable.

And neither half needs O_ALT. Introspection is statmount() with more
fields. Acquisition is a flag on open_tree()/open_tree_attr(), or an
operation on a mount fd. No new resolution mode, no second namespace
hanging off every fd, nothing for a symlink to accidentally point into.
That is the whole of my objection to the RFC, and dropping the mount
options half doesn't address any of it.

Which I think is close to your capability-fd sketch minus the tree. You
wanted privilege captured by the call that hands you the fd rather than
rechecked on use. If the only thing that call returns is a mount fd,
that's already how it behaves. And we don't have to invent a per-node
cred model or a new set of rules about what a dirfd is and isn't
allowed to do.

Giuseppe, this is also your requirement. What you actually
need is something persistable, so a restarted daemon can find the erofs
mount again without anyone having to hold an fd open for it. That's the
introspection half producing a stable identifier and the acquisition
half consuming one. Much narrower to specify than a generic metadata
tree, and it doesn't require settling anything about O_ALT first.

> Other than that question, I think I generally agree with you.  The
> interesting operations here (getting an fd to something that was
> previously inaccessible) are different enough from normal path lookups
> that I think they deserve to be explicit syscalls or syscall modes,
> not magic links.

Yes.