On Thu, 23 Jul 2026 at 11:01, Andy Lutomirski <[email protected]> wrote:
> - 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(). > - 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. > 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. > - 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. Not sure how this security model would work, though. > > - 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. > - 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. One thing I hate vehemently is directory lseek to a non-zero offset. I'd happily error out on that one. Thanks, Miklos
