On Wed, Jul 15, 2026 at 3:17 AM Miklos Szeredi <[email protected]> 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
