Re: [PATCH v6 1/4] openat2: new OPENAT2_REGULAR flag support

[Aleksa Sarai]

On 2026-04-16, Jori Koolstra <jkoolstra@xxxxxxxxx> wrote:
> 
> > Op 16-04-2026 17:15 CEST schreef Aleksa Sarai <cyphar@xxxxxxxxxx>:
> > 
> > 
> > Oh, I didn't notice that this wasn't mentioned here, we had a separate
> > discussion about it in a thread with Jori and I must've assumed we
> > discussed it in both. (My brain is also really not wired up to read
> > large octal values easily.)
> > 
> > While it is hard to add new O_* flags (hence OPENAT2_REGULAR), it's not
> > /impossible/ (Jori has a patch for OPENAT2_EMPTY_PATH that is safe to
> > add to O_* flags because of some fun historical coincidences).
> 
> But it would change userspace, at least in theory, right? If anyone for
> some reason decided to set whatever the bit will be for O_EMPTYPATH
> in a call to openat(), and pass an empty string, relying on this to fail,
> that will no longer be the case. But that is just really silly. Or are you
> hinting on something else?

Yes, such a program would break, but it is a fairly safe bet that no
such program actually exists in the wild. There is a limit to "never
break userspace" -- it actually needs to break a real userspace program
for it to matter.

Even then there are limits -- in theory someone could write a program
that would error out if any new flag is added to any syscall that
returns -EINVAL for invalid flags (in fact, we have selftests for
openat2(2) that would break because we test the error path) but it
wouldn't make sense to not add features to any syscall because such a
program could theoretically exist.

We change uAPI all the time, the trick is doing it so that userspace
doesn't notice.

For O_EMPTYPATH the logic is that programs that pass regular paths would
work the same way as they do now (i.e., LOOKUP_EMPTY semantics) and
programs that used to pass "" would previously get ENOENT -- it seems
quite unlikely anyone would depend on this for anything (they could
check if the string was empty themselves, after all) and it seems
astronomically unlikely that that they would pass garbage *and* depend
on it for anything.

(It is a little funky that open("", O_EMPTYPATH) would give you an fd to
"." but that makes more sense than the alternatives so let's just keep
it consistent.)

-- 
Aleksa Sarai
https://www.cyphar.com/

Attachment: signature.asc
Description: PGP signature