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

On Thu, Jul 23, 2026 at 2:19 AM Miklos Szeredi [off-list ref] wrote:

On Thu, 23 Jul 2026 at 11:01, Andy Lutomirski [off-list ref] wrote:

quoted

- 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().

quoted

- 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.

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

quoted

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).

This patch provides exeactly those properties.

quoted

- 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.

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.

quoted

- You can’t fchdir or (hypothetically) fchroot into it.  (Not sure 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.

quoted

- 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.

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.