Re: some other problems with chmod-safer.c, chown.c, etc.

[Paul Eggert]

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.  :-)