On Sun, Feb 28, 2021 at 4:02 PM Drew DeVault <sir@xxxxxxxxx> wrote:
>
> On Sat Feb 27, 2021 at 11:03 PM EST, Matthew Wilcox wrote:
> > > 1. Program A creates a directory
> > > 2. Program A is pre-empted
> > > 3. Program B deletes the directory
> > > 4. Program A creates a file in that directory
> > > 5. RIP
> >
> > umm ... program B deletes the directory. program A opens it in order to
> > use openat(). program A gets ENOENT and exits, confused. that's the
> > race you're removing here -- and it seems fairly insignificant to me.
>
> Yes, that is the race being eliminated here. Instead of this, program A
> has an fd which holds a reference to the directory, so it just works. A
> race is a race. It's an oversight in the API.
I think you mixed in confusion with "program B deletes the directory".
That will result, as Matthew wrote in ENOENT because that dir is now
IS_DEADDIR().
I think I understand what you mean with the oversight in the API, but
the use case should involve mkdtemp(3) - make it more like tmpfile(3).
Not that *I* can think of the races this can solve, but I am pretty sure
that people with security background will be able to rationalize this.
You start your pitch by ruling out the option of openat2() with
O_CREAT | O_DIRECTORY, because you have strong emotions
against it (loathe).
I personally do not share this feeling with you, because:
1. The syscall is already used to open directories as well as files
2. The whole idea of openat2() is that you can add new behaviors
with new open_how flags, so no existing app will be surprised from
behavior change of O_CREAT | O_DIRECTORY combination.
For your consideration.
Thanks,
Amir.
