Re: [RFC PATCH] fs: introduce mkdirat2 syscall for atomic mkdir

On Sun, Feb 28, 2021 at 4:02 PM Drew DeVault [off-list ref] wrote:

On Sat Feb 27, 2021 at 11:03 PM EST, Matthew Wilcox wrote:

quoted

quoted

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.