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

[Paul Eggert]

Jim Meyering <address@hidden> writes:

> As for the use of chmod_safer in mknod.c, bearing in mind that it is
> called only for a device that has just been created, does it matter
> if there might be such a side effect?

Yes, I think it matters.  Someone may be using mknod, for example, to
create a distribution that contains a device file.  The device file is
not intended for use on the system that invokes mknod; it is intended
for use on some other system (because the device file will be copied
onto some DVD-ROM and then mounted on the other system, say).  It
could be quite bad if that invocation of mknod had a side effect of
rewinding the tape on the _developer's_ machine.

Here's another problem that I didn't mention earlier.  As things
stand, mkfifo temporarily has the fifo open for read.  If some other
process then opens the fifo for write, the operating system will
notice that there is a reader, so the other process's open won't hang
waiting for a reader, like it should.  This will cause race conditions
when one process invokes "mkfifo -m 644 /tmp/foo", even if /tmp is
sticky.  To some extent this is a worse problem than the race
condition in the old mkfifo, since it can't be cured with sticky
directories.


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.

I went back and reread POSIX, and it seems to me that it allows this
change to the implementation.
<http://www.opengroup.org/onlinepubs/000095399/utilities/mkdir.html>
says that "mkdir -m 755 DIR" shall "Set the file permission bits of
the newly-created directory to the specified mode value."  But
<http://www.opengroup.org/onlinepubs/000095399/basedefs/sys/stat.h.html>
says "The file permission bits are defined to be those corresponding
to the bitwise-inclusive OR of S_IRWXU, S_IRWXG, and S_IRWXO."  Notice
that the setuid, setgid, and sticky bits are not file permission bits.
Hence "mkdir -m 755 DIR" is not required to clear the setgid bit of
DIR.  One could well argue that POSIX requires "mkdir -m 755 DIR" to
leave DIR's setgid bit alone, and that both the previous and the
current coreutils implementation is therefore nonconforming.


There are similar problems with the chown command.  (I'm not talking
about lib/chown.c here; I'm talking about src/chown-core.c.)
Unfortunately, for chown I don't see any fix other than reverting to
the previous implementation.