linux-kernel - Re: [PATCH v3 1/4] open: new O

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CAFfO_h5yHUB5UPzod9fHeRui1GgC4ofVskQB_ZsZQbwgBBf2AA@mail.gmail.com>
Date: Thu, 29 Jan 2026 23:41:35 +0600
From: Dorjoy Chowdhury <dorjoychy111@...il.com>
To: Aleksa Sarai <cyphar@...har.com>
Cc: Christian Brauner <brauner@...nel.org>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, viro@...iv.linux.org.uk, jack@...e.cz, 
	jlayton@...nel.org, chuck.lever@...cle.com, alex.aring@...il.com, 
	arnd@...db.de, adilger@...ger.ca
Subject: Re: [PATCH v3 1/4] open: new O_REGULAR flag support

On Thu, Jan 29, 2026 at 11:03 PM Aleksa Sarai <cyphar@...har.com> wrote:
>
> On 2026-01-29, Christian Brauner <brauner@...nel.org> 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@...il.com>
> > > ---
> >
> > 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.
>

It is a good suggestion. I guess we can still introduce a new
how->sfmt_allow field and have new bits (instead of keeping in sync
with S_IF* ones) that allow types and just start with regular file
allow bit for now, right? But I guess it would be cumbersome for users
as an api to use different bits?

Regards,
Dorjoy