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

On Wed, Jul 15, 2026 at 3:17 AM Miklos Szeredi [off-list ref] wrote:

This is a prototype patch. Needs to be split up!

1) O_ALT / OPEN_TREE_ALT

  These open an alternative namespace rooted at dfd - instead of resolving
  the path in the real filesystem, it resolves it in a virtual tree that
  exposes metadata about that file.

  This is intended to provide an alternative to adding new ioctls:

   - provides structured namespace
   - allows accessing data through fs ops

  Could call this O_META, but O_ALT seems more generic and there could be
  uses beyond metadata (e.g. seekable, in-place decompression).

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?
 What happens when an unsuspecting process gets such an fd?  Can you
fchdir to it?  chroot to it?  clone its tree and possibly bind-mount
it somewhere?

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

3. Whose creds are used for which operations?

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

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?

--Andy

-- 
Andy Lutomirski
AMA Capital Management, LLC