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

On Thu, Jul 23, 2026 at 2:19=E2=80=AFAM Miklos Szeredi <[email protected]> =
wrote:
>
> 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 =
that 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/bl=
ah can access something that ought to be inaccessible when accessed intenti=
onally and with privilege, a symlink pointing at /proc/something/=E2=80=A6 =
can cause the API to be used inadvertently.  Admittedly we have this proble=
m 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 trave=
rsal and opening, and mapping this nicely only new APIs (as opposed to actu=
al 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 prop=
osal) that we should have proper capability-like fds, and maybe that=E2=80=
=99s 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 =
only accessible via one of the newer and less janky open variants?  And wha=
t if the resulting fd and the filesystem tree it represented had a few prop=
erties that made it very different from normal directory fds:
> >
> > - You cannot mount anything on it or its subdirectories, nor can you op=
en_tree or otherwise mount it anywhere.  But you can open_tree the very spe=
cific things in it that point outside of the special API (e.g. the overlayf=
s 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 y=
ou might need privileges over your own namespaces to do operations that mig=
ht affect them.
>
> This is trivial to add to metafs: just store a ref to current->cred
> besides the path.

We have f_cred that might be good enough, although I'm not sure it
propagates through path lookup.

>
> Not sure how this security model would work, though.

If I have CAP_SYS_ADMIN and I open the metafs and then drop privilege,
then I would still be able to do all the metafs operations as if I had
CAP_SYS_ADMIN so long as I use the fd I opened to do those operations.

>
> >
> > - You can=E2=80=99t fchdir or (hypothetically) fchroot into it.  (Not s=
ure 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 u=
se 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.

I'll sleep on it.  Maybe it's all fine.