Re: [PATCH v3 09/14] vfs: add O_CREAT|O_DIRECTORY to open*(2)

[Jori Koolstra]

> Op 22-07-2026 23:57 CEST schreef NeilBrown <neilb@xxxxxxxxxxx>:
> 
>  
> On Wed, 22 Jul 2026, Jori Koolstra wrote:
> > 
> > If you want your software to be compatible with any Frankenstein-kernel
> > you just check what you O_CREATed is in fact a directory. If it is and
> > there is no EINVAL/EISDIR, you are running a supported kernel,
> > if it isn't, you're not.
> > 
> > Or you just require a minimal reasonable kernel version.
> 
> Without getting all the arguments about how people should write their
> apps and choose their kernels.....
> 
> Given how easy it would be to make this bullet proof by adding a "fail
> if this combination isn't explicit permitted" flag to openat2 - why
> don't we just do that so that it is EASY to write as safe app and EASY
> to choose a kernel (i.e. any kernel at all with do).

There are two potential issues with this approach, neither of them definitively
killing the idea, but still:

1. Afaik, openat2 used to (or still is?) blocked by many seccomp-profiles,
   in particular by systemd. And frankly, a lot of UAPI changes are driven
   by the needs of these large user space applications, so it may defeat
   some of the purpose if these applications cannot use the discovery
   mechanism.

2. Matter of style: openat2 should just be about opening files, I'd rather
   not multiplex is to also do feature discovery.

Actually, why isn't there a has_feature(2) syscall that takes the syscall # as
argument and some other struct describing a feature. Then when adding a new
feature that may need discovery, require to extend it in the same patch series,
then not even Frankenstein-kernels can get in trouble.

Anyway, it is up to Christian.

Best,
Jori.