Jim Meyering <[EMAIL PROTECTED]> writes: > Paul Eggert <[EMAIL PROTECTED]> wrote: >> For mkdir, mknod, and mkfifo, how about this idea instead? If -m is >> used, use only the umask to set the file permission bits; do not use >> chmod (or fchmod) at all. That way, there won't be any race >> conditions at all. > > Do other versions of these tools work that way?
I just checked FreeBSD CVS, and its mkfifo works that way. Its mknod doesn't have an -m option, so there's no analogy there. Finally, its mkdir behaves that way, if the -m argument specifies only the file permission bits (777). If the -m argument also specifies other bits, mkdir follows up with chmod; presumably this is relying on the fact that POSIX does not specify the behavior in this case. For what it's worth, Solaris 10 mkdir -m and mkfifo -m always use the chmod function. > If we do adopt the change-only-file-permission-bits approach, specifying > the now-ignored bits would have to elicit a warning or error. That's what I thought at first, but I just now noticed that Google finds about 353 uses of "mkdir -m 1777". See, for example, <http://www.wlug.org.nz/PerUserTempDirs>. There are smaller numbers of usages of "mkdir -m 2755" and the like. So, for mkdir I'm inclined to take the FreeBSD approach, as it's compatible. For mkfifo I'm inclined also to take the FreeBSD approach, except that the now-ignored bits should elicit an error. mknod can be like mkfifo. I don't know of any real-world apps that this will break, on ordinary systems. Possibly it will break in some ACL environments but I think we can defer worrying about that until we see what the actual problems are. Even with this change, we will still have the problem with the chown command though; CVS chown still opens the file it chowns, which can cause real trouble as mentioned earlier. > While in some places POSIX seems to require that only ugo/rwx bits be > affected, this part of the spec (from mkdir) seems to imply otherwise: > > -m mode Set the file permission bits of the newly-created directory > to the specified mode value. The mode option-argument shall > be the same as the mode operand defined for the chmod utility. As I read it, this means if you invoke "mkdir -m 1777" then you are relying on unspecified behavior, since the spec says only that the file permission bits will be set. (I could ask for a clarification from POSIX but I'd like to know first what we want to do. :-) _______________________________________________ Bug-coreutils mailing list [email protected] http://lists.gnu.org/mailman/listinfo/bug-coreutils
