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

[Jim Meyering]

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'll go along, as long as the change doesn't introduce
a new incompatibility with other versions of those tools.
I didn't even think of that approach because of an ingrained
assumption that the MODE argument to e.g., mkdir, should be
treated just as it would be treated by chmod.

If we do adopt the change-only-file-permission-bits approach, specifying
the now-ignored bits would have to elicit a warning or error.

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.

Another reason to like the umask-only (no-chmod call) approach is that
POSIX (mkfifo) prohibits doing what I did (create with u=r) to ensure
that mknod,mkfifo,mkdir are able to open the just-created target file
even when the requested MODE would prohibit user-read access:

    (If the -m option is specified, the value of the mkfifo() mode
    argument is unspecified, but the FIFO shall at no time have
    permissions less restrictive than the -m mode option-argument.)