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

On Thu, 23 Jul 2026 at 11:01, Andy Lutomirski <[email protected]> wrote:

> - O_XYZ flags to open() are all kinds of awful, for historical reasons th=
at are not fundamental to the concept.

I'm fine with limiting this to openat2().

> - symlinks. If we have a new API where opening /proc/something/magic/blah=
 can access something that ought to be inaccessible when accessed intention=
ally and with privilege, a symlink pointing at /proc/something/=E2=80=A6 ca=
n cause the API to be used inadvertently.  Admittedly we have this problem =
with basically all symlinks, so this isn=E2=80=99t exactly unique.
>
> - our nasty fs permission model. We gave a sort of gnarly mix of a bit of=
 fd-based permission and mostly mode/ACL-based permissions for path travers=
al and opening, and mapping this nicely only new APIs (as opposed to actual=
 files and directories) can have unpleasant results.

Pseudo filesystems don't usually do mode/acl based permission checks.
 I don't see any issue with that.

> Of course, I=E2=80=99m busy arguing (slowly and without a concrete propos=
al) that we should have proper capability-like fds, and maybe that=E2=80=99=
s kind of an answer to this:
>
> What if we had an API to get an fd to the =E2=80=9Ccontrol filesystem=E2=
=80=9D for a superblock, like your O_ALT but as a real syscall or maybe onl=
y accessible via one of the newer and less janky open variants?  And what i=
f the resulting fd and the filesystem tree it represented had a few propert=
ies that made it very different from normal directory fds:
>
> - You cannot mount anything on it or its subdirectories, nor can you open=
_tree or otherwise mount it anywhere.  But you can open_tree the very speci=
fic things in it that point outside of the special API (e.g. the overlayfs =
layers).

This patch provides exeactly those properties.

> - Privilege is fully captured by the original call that gets you the fd. =
 current->cred is not checked when *using* it except to the extent that you=
 might need privileges over your own namespaces to do operations that might=
 affect them.

This is trivial to add to metafs: just store a ref to current->cred
besides the path.

Not sure how this security model would work, though.

>
> - You can=E2=80=99t fchdir or (hypothetically) fchroot into it.  (Not sur=
e how important this is.)

Not sure if there are internal mounts that have directories?  If not,
we can just add a check to fchdir/chroot against mnt_ns being NULL.

> - Maybe you can=E2=80=99t follow /proc/pid/fd/N links into it either?  Or=
 maybe that would break CRIU too badly.
>
> The basic idea here is to try to treat it like an API that happens to use=
 the open machinery but not as part of the filesystem hierarchy.

I'm not opposed to limiting this in various ways, though I don't
really see the advantage.

One thing I hate vehemently is directory lseek to a non-zero offset.
I'd happily error out on that one.

Thanks,
Miklos