Paul Eggert <[EMAIL PROTECTED]> 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 _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
