[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: some other problems with chmod-safer.c, chown.c, etc.
From: |
Paul Eggert |
Subject: |
Re: some other problems with chmod-safer.c, chown.c, etc. |
Date: |
Sun, 01 Jan 2006 17:23:49 -0800 |
User-agent: |
Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) |
Jim Meyering <address@hidden> writes:
> Paul Eggert <address@hidden> 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. :-)