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

On Sun, 19 Jul 2026 at 16:13, Andy Lutomirski [off-list ref] wrote:

This gives me the willies a bit.  It's very cool, but it has some
potential security issues that I think we need to watch out for.  As
sort-of prior art, NTFS supports alternate streams and Reiser4, ahem,
supported files-as-directories.

Some questions that we would need to consider:

1. Can you open an fd referring to a "directory" within an O_ALT tree?

Yes.

 What happens when an unsuspecting process gets such an fd?  Can you
fchdir to it?  chroot to it?

Yes.   However you cannot escape from that particular base file's O_ALT tree.

 clone its tree and possibly bind-mount
it somewhere?

No, it's an "internal" mount, so no cloning.

2. Can you bind-mount *onto* something inside O_ALT?

Again, no, because it's an internal mount, not in any mount namespace.

3. Whose creds are used for which operations?

The creds of the process doing the operation.

4. Can you mmap the things in O_ALT?  Is this determined per object or
generically?

Per object.

5. Would we ever allow FUSE to expose custom things inside O_ALT?
What contents of O_ALT can a program trust come from the kernel and
have the expected semantics?

I think adding such a plugin would be similar to adding a mount.  So
I'd suggest allowing it with the same privs (CAP_SYS_ADMIN) and
constraints (limited to the current mount namespace).

Thanks,
Miklos