Re: chdir-safer can go?

[Jim Meyering]

Paul Eggert <address@hidden> wrote:
> As a result of the recent changes, the files lib/chdir-safer.c,
> lib/chdir-safer.h, and m4/chdir-safer.m4 can be removed from
> coreutils.  This is because mkdir-p no longer uses the open/fchdir
> method; it simply uses mkdir, on the theory that you can't close the
> race condition between mkdir and the next operation anyway, and the
> file names are typically so short that there's no real performance
> benefit to the O(N) algorithm.

> Any objections to removing the chdir-safer files?  I guess we can
> bring them back later if we find a use for them.  (On the other hand,
> maybe you want me to try to bring back the O(N) algorithm....)

Hi Paul,

Thanks for all of that work.

If we cared only about "typical" cases, we'd be able to remove a whole
lot of the code in the coreutils :-)  That said, I recognize that mkdir
is a little different than say cp, chown, or rm, since all of its
file-component operands appear on the command line.  If it were just
a question of an O(N) implementation vs. a simpler-but-O(N^2) one,
especially where N is bounded by about 2000 or 4000 on most systems,
I'd probably say "ok".

BTW, did you do any timings?  What's the worst-case performance hit on a
local file system?  on NFS?

Efficiency aside, why reintroduce the race condition between a successful
mkdir (e.g., as called through mkdir -p) and the subsequent operation on
the resulting directory?  With chdir_no_follow, for each successful mkdir
call, we were guaranteed that an attempt to replace that just-created
directory with a symlink would be detected.  Now, there is no such
guarantee.

True, even with chdir_no_follow, there is a race in that an attacker
can replace a just-created empty directory with a different _directory_.
But that poses very little risk.

I'd prefer an implementation that provides protection against the
replace-just-created-dir-with-symlink race condition.

Jim