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

[Paul Eggert]

I noticed a problem with chown.c (when CHOWN_MODIFIES_SYMLINK) and
chmod-safer.c.  If the file being chmod'ed or chown'ed is a special
file, opening it can cause undesirable side effects.  For example, it
might cause a tape drive to be rewound.

Also, the current implementations of mkdir, mkfifo, and mknod arrange
for files to be temporarily readable to the owner, even when the
requested mode is that the file not be readable to the owner.  In the
traditional Unix model this doesn't introduce a security-related race
condition, since an attacker with owner (or root) privileges can set
the file to be readable anyway.  But in the ACL world I'm not sure
this holds: that is, isn't it possible that granting the owner
temporary read permission can cause a real hole?

Also, if a directory is temporarily mode 400, that can cause problems
with other processes running 'find'.  Surely the temporary mode (if we
want to continue to use it) should be 400 OR'ed in with the desired
mode, not 400.

It's not clear to me that these are the only problems with the code;
there are some other fairly subtle issues involved, which I don't
entirely follow.

A bigger issue: it's not clear to me how much safety chmod_safer adds.
For example, if /tmp is world-writeable and is not sticky, then "mkdir
-m 755 /tmp/a/b" is unsafe even with chmod_safer in place, since the
attacker can replace /tmp/a with a symlink.  Another example: "mkdir
-m 755 /tmp/a" is unsafe if the attacker can rename /tmp/a and rename
a victim directory to /tmp/a before mkdir gets around to invoking
chmod on what it thinks is the newly created /tmp/a.

I suspect that users who share world-writeable directories with
untrusted users are fundamentally at risk, and that we cannot fix
coreutils to be "secure" in that situation.  If so, perhaps we
shouldn't bother to try, if trying causes problems in other areas.