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