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
