Re: proposed fix for some race conditions in mkdir and install

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Jim Meyering <address@hidden> writes:
>>> I initially tried something like that, but got too confused by it,
>>> perhaps partly because I wanted to fall back on something like the
>>> current approach when mkdirat didn't work (which is a common case
>>> these days, even on GNU/Linux systems, alas).
>>
>> What do you mean?
>> Of course, for at-function-syscall support, you need Linux 2.6.16 or
>> newer, but gnulib's mkdirat emulation works well also with /proc/self/fd/N
>> support, which is available back at least to linux-2.4.x.
>> Admittedly, /proc isn't always available, but I wouldn't say that's "common".
>
> I was thinking of the "/proc isn't available" case.
> You're right, it's not that common, but we do
> get bug reports....

I do recall one bug report that ended up being due to a misconfigured
system: /proc was unreadable.  And of course, even with a kernel that
supports /proc, you can create a chroot environment that lacks /proc
altogether.  But even there, the save-cwd-based emulation works fine
except in the very unusual case where the working directory cannot be
saved or restored.  Then, consider the rare cases in which it fails, but
would otherwise be able to do useful work, and you realize that it just
doesn't matter.  Those cases are just too contrived: working directory
too deep (longer than PATH_MAX) for getcwd to work, or recursing into
some subtree and then trying to create something in a writable, but
unreadable initial working directory.  Some would say we have to be over
the edge to think up such extreme scenarios.

As far as I recall, there have been *no* reports of gnulib's
at-function _emulation_ layer failing.

For me, the important thing is to use the "right" (clean, modern,
standard[*]) APIs.  In my book, that means using openat, mkdirat, etc.
to solve this sort of problem, not the thread-unsafe chdir.

[*] in that order :-)

We should be coding for the future.
If all systems will eventually end up providing openat support (IMHO, they
will), then we should feel free to use it now, as long as the emulation
layer is "good enough".  Just as we don't mind imposing some overhead
or small additional risk on old and deficient systems through wrapper
functions, we can and should do the same when it comes to slightly more
modern systems that lack features we think are important enough.

> I was also worried a bit about bugs in /proc itself, which are more
> likely to be tickled by these usages.  For example:
>
> mkdir -p /proc/self/fd/0/../tmp/foo </
>
> where if we use /proc/self/fd internally, then we're in effect using
> /proc/self/fd once on itself.  It _should_ work, even when the file
> name crosses mount points, but _does_ it?  (I'm almost afraid to try.
> :-)

That's truly twisted :-)
But we shouldn't let the *possibility* of a bug affecting an emulation
layer (*if* there is such a bug, it'll matter only on old systems)
determine whether to use a superior API.