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

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> Like most utilities, mkdir and install are vulnerable to race
> conditions involving file names, e.g., if given a file name that
> resolves through a non-sticky directory that is writeable by some
> other user.  Here's a patch to fix that, just for these two utilities.
> It's a bit outre, since it requires forking off a subprocess in some
> cases, but it should resist the race condtions better.
>
> I'll attach two patches, one for gnulib and one for coreutils.

Hi Paul,

Thanks for all that work.
At first glance, those changes look fine.
You're welcome to check them in.

However, it's a shame that these gnulib functions aren't thread-safe --
they change the working directory.
Of course, I realize why they are that way: so that the dir-creation
functions work even in the unusual event that the parent of a target
directory is writable, but unreadable.

By the way, I've just realized that it *is* possible to implement these
mkdir-like functions in a thread-safe manner (i.e. traversing via openat,
operating on files via mkdirat, chmodat, etc.), while remaining efficient
(O(n)).  The only assumption is that the target directory name does not
contain too long a sequence of existing unreadable directories (sum
of length of names + slashes > PATH_MAX).  And such a scenario is so
far-fetched that even I am willing to ignore it.  That said, as long as
these functions are unlikely to be used in a multi-threaded environment,
I see no pressing need to convert them.

One nit:

In tests/install/basic-1, there are two 2-line comments that
are essentially identical:

  # Test that we can install from an unreadable directory with an inaccessible 
parent.
  # coreutils 5.97 fails this test.
  ...

  # Test whether you can install from a directory that is not readable
  # and whose parent is not accessible.  coreutils 5.97 fails this test.