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

> On Jul 23, 2026, at 10:22=E2=80=AFAM, Miklos Szeredi <[email protected]> w=
rote:
>=20
> =EF=BB=BFOn Wed, 22 Jul 2026 at 18:36, Andy Lutomirski <[email protected]=
t> wrote:
>=20
>> 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.
>=20
> This is a super specialized use case.
>=20
> I sort of agree that doing statmount() as a syscall was not a bad
> idea.   But new syscall for getting a backing layer, that makes sense
> on just a couple of filesystems?
>=20
> And that leaves us with ioctl.   And ioclt() returning an open fd has
> it's own problems, besides ioctl being a generally bad interface.
>=20
> And we have all these powerful concepts and interfaces for
> filesystems, why the big resistance to actually using them?.
>=20
> Sure, it's easy to misuse, but I don't yet see why this particular
> case would be a misuse.  Enlighten me please.
>=20

I think there are are a couple of complications involved with open, openat, e=
tc that aren=E2=80=99t present with explicit for-the-purpose syscalls:

- O_XYZ flags to open() are all kinds of awful, for historical reasons that a=
re not fundamental to the concept.

- symlinks. If we have a new API where opening /proc/something/magic/blah ca=
n access something that ought to be inaccessible when accessed intentionally=
 and with privilege, a symlink pointing at /proc/something/=E2=80=A6 can cau=
se the API to be used inadvertently.  Admittedly we have this problem with b=
asically 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 traversal a=
nd opening, and mapping this nicely only new APIs (as opposed to actual file=
s and directories) can have unpleasant results.

Of course, I=E2=80=99m busy arguing (slowly and without a concrete proposal)=
 that we should have proper capability-like fds, and maybe that=E2=80=99s ki=
nd 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 acces=
sible via one of the newer and less janky open variants?  And what if the re=
sulting fd and the filesystem tree it represented had a few properties that m=
ade it very different from normal directory fds:

- You cannot mount anything on it or its subdirectories, nor can you open_tr=
ee or otherwise mount it anywhere.  But you can open_tree the very specific t=
hings in it that point outside of the special API (e.g. the overlayfs layers=
).

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

- You can=E2=80=99t fchdir or (hypothetically) fchroot into it.  (Not sure h=
ow important this is.)

- Maybe you can=E2=80=99t follow /proc/pid/fd/N links into it either?  Or ma=
ybe that would break CRIU too badly.

The basic idea here is to try to treat it like an API that happens to use th=
e open machinery but not as part of the filesystem hierarchy.

One could go even farther and try to remove a bunch of the parts that make i=
mplementing it tedious.  For example, if this hierarchy had =E2=80=9C/layers=
/1/options=E2=80=9D, there is really no reason to over open an fd to layers o=
r layers/1, and if we had a readfile syscall there wouldn=E2=80=99t be a rea=
son to open an fd to options either.  But maybe this is a silly direction to=
 move in.

> Thanks,
> Miklos