On Thu, 2026-04-16 at 23:05 +1000, Aleksa Sarai wrote: > On 2026-04-16, Dorjoy Chowdhury <[email protected]> wrote: > > On Thu, Apr 16, 2026 at 5:41 PM Aleksa Sarai <[email protected]> wrote: > > > > > > On 2026-03-28, 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]. > > > > > > > > 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. > > > > > > > > When used in combination with O_CREAT, either the regular file is > > > > created, or if the path already exists, it is opened if it's a regular > > > > file. Otherwise, -EFTYPE is returned. > > > > > > > > When OPENAT2_REGULAR is combined with O_DIRECTORY, -EINVAL is returned > > > > as it doesn't make sense to open a path that is both a directory and a > > > > regular file. > > > > > > > > [1]: > > > > https://uapi-group.org/kernel-features/#ability-to-only-open-regular-files > > > > > > > > Signed-off-by: Dorjoy Chowdhury <[email protected]> > > > > --- > > > > > > Aside from the nit below, feel free to take a > > > > > > Reviewed-by: Aleksa Sarai <[email protected]> > > > > > > > Thanks for reviewing! > > > > > > diff --git a/fs/open.c b/fs/open.c > > > > index 681d405bc61e..a6f445f72181 100644 > > > > --- a/fs/open.c > > > > +++ b/fs/open.c > > > > @@ -960,7 +960,7 @@ static int do_dentry_open(struct file *f, > > > > if (f->f_mapping->a_ops && f->f_mapping->a_ops->direct_IO) > > > > f->f_mode |= FMODE_CAN_ODIRECT; > > > > > > > > - f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC); > > > > + f->f_flags &= ~(O_CREAT | O_EXCL | O_NOCTTY | O_TRUNC | > > > > OPENAT2_REGULAR); > > > > > > It's not clear to me why you dropped this, I didn't see a review > > > mentioning it either. (General note: Ideally the cover letter changelog > > > would mention who suggested a change in brackets after the changelog > > > line so it's easier to track where a change might've come from.) > > > > > > > Thanks for the general note. I will keep that in mind. > > > > The review was from Jeff Layton in v5 > > https://lore.kernel.org/linux-fsdevel/[email protected]/ > > " 1. OPENAT2_REGULAR leaks into f_flags - do_dentry_open() strips > > open-time-only flags (O_CREAT|O_EXCL|O_NOCTTY|O_TRUNC) > > but does not strip OPENAT2_REGULAR. When a regular file is > > successfully opened via openat2() with this flag, the bit > > persists in file->f_flags and will be returned by fcntl(fd, F_GETFL)." > > > > I think it makes sense to strip off as OPENAT2_REGULAR is an open time > > only flag (like O_CREAT and the others already), right? > > Well, O_DIRECTORY isn't stripped so if we want to mirror that behaviour > then it shouldn't be stripped either IMHO. > > O_NOCTTY and O_TRUNC make sense to strip (they are not relevant to the > file after it was opened -- truncation only happens at open time and you > can always set your controlling TTY later). > > The story with O_CREAT and O_EXCL is a bit more complicated. They are > stripped but the history there is unclear -- the line was added in Linux > 0.98.4(!) with no mention in the release note at the time. (Linus: I > wonder if you remember why this was changed at the time? Sorry for the > trip down memory lane...) > > However, the existence of F_CREATED_QUERY kind of shows that these kinds > of checks are stuff that userspace can find handy (though FMODE_CREATED > is more useful than O_CREAT|O_EXCL anyway). O_EXCL is used internally > for stuff so it can be re-exposed, I'm just not sure it's a good > precedent to make a decision based on. > > Then again, userspace can check with fstat(2) so it's not the end of the > world, but I don't really see a strong reason to hide information from > userspace. Since the mail was from Claude (and it tends to give silly > nits like that) I'm not sure whether Jeff would agree with my view or > not.
I don't have a strong feeling either way, but it "feels" like O_REGULAR is not particularly useful to return in F_GETFL. Once the file is open, then O_REGULAR really doesn't matter anymore. We _know_ it's a regular file at that point or the open wouldn't have happened. F_GETFL is more useful for showing flags that actually affect how the file description works (e.g. O_DIRECT, O_ASYNC, etc.). -- Jeff Layton <[email protected]>
