> On Jul 23, 2026, at 10:22 AM, Miklos Szeredi <[email protected]> wrote:
>
> On Wed, 22 Jul 2026 at 18:36, Andy Lutomirski <[email protected]> wrote:
>
>> 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.
>
> This is a super specialized use case.
>
> 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?
>
> And that leaves us with ioctl. And ioclt() returning an open fd has
> it's own problems, besides ioctl being a generally bad interface.
>
> And we have all these powerful concepts and interfaces for
> filesystems, why the big resistance to actually using them?.
>
> Sure, it's easy to misuse, but I don't yet see why this particular
> case would be a misuse. Enlighten me please.
>
I think there are are a couple of complications involved with open, openat, etc
that aren’t present with explicit for-the-purpose syscalls:
- O_XYZ flags to open() are all kinds of awful, for historical reasons that are
not fundamental to the concept.
- symlinks. If we have a new API where opening /proc/something/magic/blah can
access something that ought to be inaccessible when accessed intentionally and
with privilege, a symlink pointing at /proc/something/… can cause the API to be
used inadvertently. Admittedly we have this problem with basically all
symlinks, so this isn’t 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
and opening, and mapping this nicely only new APIs (as opposed to actual files
and directories) can have unpleasant results.
Of course, I’m busy arguing (slowly and without a concrete proposal) that we
should have proper capability-like fds, and maybe that’s kind of an answer to
this:
What if we had an API to get an fd to the “control filesystem” 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 what if the resulting fd
and the filesystem tree it represented had a few properties 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 specific things
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.
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.
- You can’t fchdir or (hypothetically) fchroot into it. (Not sure how
important this is.)
- Maybe you can’t 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.
One could go even farther and try to remove a bunch of the parts that make
implementing it tedious. For example, if this hierarchy had
“/layers/1/options”, there is really no reason to over open an fd to layers or
layers/1, and if we had a readfile syscall there wouldn’t be a reason to open
an fd to options either. But maybe this is a silly direction to move in.
> Thanks,
> Miklos
