On Sun, Mar 8, 2026 at 4:40 AM Jeff Layton <[email protected]> wrote: > > On Sat, 2026-03-07 at 10:56 -0800, Andy Lutomirski wrote: > > On Sat, Mar 7, 2026 at 6:09 AM Dorjoy Chowdhury <[email protected]> > > wrote: > > > > > > This flag indicates the path should be opened if it's a regular file. > > > This is 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 a requested feature from the > > > uapi-group[1]. > > > > > > > I think this needs a lot more clarification as to what "regular" > > means. If it's literally > > > > > A corresponding error code EFTYPE has been introduced. For example, if > > > openat2 is called on path /dev/null with OPENAT2_REGULAR in the flag > > > param, it will return -EFTYPE. EFTYPE is already used in BSD systems > > > like FreeBSD, macOS. > > > > 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? > > > > Above the use-case, it also says: > > "O_REGULAR (inspired by the existing O_DIRECTORY flag for open()), > which opens a file only if it is of type S_IFREG." > > Since we allow programs to open a directory under /proc or /sys using > O_DIRECTORY, I don't think we should do anything different here. To the > VFS, all of the examples you gave above are S_IFREG "regular files", > even if they are backed by something quite irregular.
That's certainly a valid and consistent way to define this, but is it useful? --Andy
