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

On Wed, 22 Jul 2026 at 18:06, Christian Brauner [off-list ref] wrote:

We've added a primary set of apis to retrieve mount options. I really
dislike the idea of introducing a completely orthogonal layer to do the
same thing (or more) and also make it filesystem based while at it.

Fair enough.

The other proposal of moving it into procfs doesn't lower the creepiness
factor. It just paints it a different color. My objection is to the
shape of this not where the entry point lives.

Also fair point.  The reason I like the proc entry point is that it
makes this accessible in the global namespace.

Like, I'm fine having 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 seems something we can potentially do.

That's exactly what I was proposing.  The "retrieve all mount options"
was a bad idea.  Will drop it.

There's a few issues on top of that. O_ALT is silently ignored unless
you spell the open as openat(dirfd, relative, ...). path_init() only
looks at LOOKUP_ALT in the dirfd branch. open("/abs", O_ALT) and
openat(AT_FDCWD, "rel", O_ALT) fall straight through and open the real
file.

Good point.   It should either reject the non fd case (including plain
open(2) or use cwd as the base.  I'm leaning towards the former.

The layer symlinks are an unchecked jump into internal, out-of-namespace
mounts. Following mount/options/upperdir/0 ends in nd_jump_link(). That
doesn't do permission checks and no mnt_ns check.

It should do the permission check, will fix.

It's jumping into an anonymous mount, why should it check mnt_ns?

The overlay upper/lower layers are internal mounts with no mountpoint in
any namespace. So any unprivileged process that can open the overlay
root gets an O_PATH handle to a layer root it has no search-permission
path to and on a mount outside its namespace and can then use it as a
dirfd.

It's just missing the permission check in metafs_path_get_link().

Pulling the mount out is gated by CAP_SYS_ADMIN, but the handle and the
traversal are not. That's exactly Andy's "whose creds" question, it's
inherent to the design, and the procfs variant has it too.

Maybe I'm not getting something.   Why would the metafs based design
be more limited in how it checks permission and with which creds than
any other interface?

get_options() forks ->show_options() permanently. It's added
alongside the existing method and mnt_show_options() now tries one then
the other.

That leaves the tree split forever or commits us to a flag-day
conversion of everything. The new thig is also heavie and loses the
seq_file overflow-retry. All so the 99% of filesystems that will never
expose a path option can carry a more complicated interface.

This is something that would be useful anyway.  Would prevent the back
and forth escaping for statmount.  I can do a full conversion patch
either with coccinelle or claude in a couple hours.   And nothing is
lost, the layer above seq_file is just an abstract class, could make
it call exactly the same seq_file ops as before.

mnt_devname to s_devname move is a behavioral change. alloc_super()
records fc->source only on the sb-create path in sget_fc(). Sharing an
existing sb path never updates it. For filesystems that share a
superblock across mounts every mount now reports the first mounter's
source in /proc/self/mountinfo and statmount().

Well, drat.  Doesn't really matter, though.

And the smaller details really show how inelegant this model is and why
Al and I have opposed it multiple times before. Scalar options are
modeled as symlinks and non-path options are dangling links whose
readlink still returns the value while for path options readlink returns
the option string but following the link jumps somewhere else entirely.

Hey, this is was a prototype to show that this can do what Giuseppe
needs.  Not with nicely polished interfaces.

Completely agree with you, that's a shitty interface that I've done in
there.  Not proud of it.

But that's completely besides the point.  The point is that it would
allow a lot of things to be done more elegantly, without adding
special interfaces all over the place.

But a generic metadata interface layered on top of yet another magic
filesystem whether it's mounted or hidden behind procfs I feel very
strongly about. I also have great difficulty seeing Al supporting it.

Me too, as you have obviously noted.

I'm going offline for two weeks starting this weekend, so no lengthy
and heated discussions for a while.

But I'll be back!  HA HA HA ha

Thanks,
Miklos