On 2026-03-09, Christian Brauner <[email protected]> wrote: > > > On Sat, 2026-03-07 at 10:56 -0800, Andy Lutomirski wrote: > > > > I think this needs more clarification as to what "regular" means, > > > > since S_IFREG may not be sufficient. The UAPI group page says: > > > > > > > > Use-Case: this would be very useful to write secure programs that want > > > > to avoid being tricked into opening device nodes with special > > > > semantics while thinking they operate on regular files. This is > > > > particularly relevant as many device nodes (or even FIFOs) come with > > > > blocking I/O (or even blocking open()!) by default, which is not > > > > expected from regular files backed by “fast” disk I/O. Consider > > > > implementation of a naive web browser which is pointed to > > > > file://dev/zero, not expecting an endless amount of data to read. > > > > > > > > What about procfs? What about sysfs? What about /proc/self/fd/17 > > > > where that fd is a memfd? What about files backed by non-"fast" disk > > > > I/O like something on a flaky USB stick or a network mount or FUSE? > > > > > > > > Are we concerned about blocking open? (open blocks as a matter of > > > > course.) Are we concerned about open having strange side effects? > > > > Are we concerned about write having strange side effects? Are we > > > > concerned about cases where opening the file as root results in > > > > elevated privilege beyond merely gaining the ability to write to that > > > > specific path on an ordinary filesystem? > > I think this is opening up a barrage of question that I'm not sure are > all that useful. The ability to only open regular file isn't intended to > defend against hung FUSE or NFS servers or other random Linux > special-sauce murder-suicide file descriptor traps. For a lot of those > we have O_PATH which can easily function with the new extension. A lot > of the other special-sauce files (most anonymous inode fds) cannot even > be reopened via e.g., /proc.
Indeed, I see OPENAT2_REGULAR as a way of optimising the tedious checks that userspace does using O_PATH+/proc/self/fd/$n re-opening when dealing with regular files. For the problem of stuck NFS handles and so on, an idea I've had on my backlog for a long time was RESOLVE_NO_REMOTE that would block those kinds of things. IMHO it doesn't make sense to block those things with an O_* flag because (especially in the NFS example) directory components can also cause the syscall to block indefinitely and so RESOLVE_* flags make more sense for this anyway. But in my mind this is a separate problem to OPENAT2_REGULAR. -- Aleksa Sarai https://www.cyphar.com/
signature.asc
Description: PGP signature
