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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2021-03-02, Amir Goldstein <amir73il@xxxxxxxxx> wrote:
> 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

Al NACKed doing it as part of open[1]. My understanding is that the main
two reasons for that were:

 1. open() and mkdir() have different semantics for resolving paths. For
	instance, open(O_CREAT) will create a file at the target of dangling
	symlink but mkdir() will not allow that. I believe there's also some
	funky trailing-"/" handling with mkdirat() as well.

 2. Adding more multiplexers is bad. openat2(2)

I think (1) alone is a strong enough justification, since I don't think
there's precedent for having two different path lookup semantics in the
same VFS syscall.

> 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.

While it is true that you *could* do this with openat2(), the intention
of openat2() was to allow us to add new arguments openat() if those
arguments make sense within the context of an "open" operation.

(An example would be the opath_mask stuff which I included in the
original series, and am working on re-sending -- that is an additional
argument for O_PATH, and is still clearly linked to opening something.)

[1]: https://lore.kernel.org/linux-fsdevel/20200313182844.GO23230@xxxxxxxxxxxxxxxxxx/

-- 
Aleksa Sarai
Senior Software Engineer (Containers)
SUSE Linux GmbH
<https://www.cyphar.com/>

Attachment: signature.asc
Description: PGP signature


[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux