Re: [PATCH v3 1/4] open: new O_REGULAR flag support
From: Aleksa Sarai
Date: Thu Jan 29 2026 - 12:06:31 EST
On 2026-01-29, Christian Brauner <brauner@xxxxxxxxxx> wrote:
> On Tue, Jan 27, 2026 at 11:58:17PM +0600, Dorjoy Chowdhury 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.
> >
> > A corresponding error code ENOTREG has been introduced. For example, if
> > open is called on path /dev/null with O_REGULAR in the flag param, it
> > will return -ENOTREG.
> >
> > 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, -ENOTREG is returned.
> >
> > -EINVAL is returned when O_REGULAR is combined with O_DIRECTORY (not
> > part of O_TMPFILE) because it doesn't make sense to open a path that
> > is both a directory and a regular file.
> >
> > Signed-off-by: Dorjoy Chowdhury <dorjoychy111@xxxxxxxxx>
> > ---
>
> Yeah, we shouldn't add support for this outside of openat2(). We also
> shouldn't call this OEXT_* or O2_*. Let's just follow the pattern where
> we prefix the flag space with the name of the system call
> OPENAT2_REGULAR.
>
> There's also no real need to make O_DIRECTORY exclusive with
> OPENAT2_REGULAR. Callers could legimitately want to open a directory or
> regular file but not anything else. If someone wants to operate on a
> whole filesystem tree but only wants to interact with regular files and
> directories and ignore devices, sockets, fifos etc it's very handy to
> just be able to set both in flags.
>
> Frankly, this shouldn't be a flag at all but we already have O_DIRECTORY
> in there so no need to move this into a new field.
You could even say O_NOFOLLOW is kinda like that too.
In my other mail I proposed a bitmask of S_IFMT to reject opening (which
would let you allow FIFOs and regular files but block devices, etc).
Unfortunately I forgot that S_IFBLK is S_IFCHR|S_IFDIR. This isn't fatal
to the idea but it kinda sucks. Grr.
> Add EFTYPE as the errno code. Some of the bsds including macos already
> have that.
--
Aleksa Sarai
https://www.cyphar.com/
Attachment:
signature.asc
Description: PGP signature