chown regression from coreutils 5.2.1 for execute-only files

[Paul Eggert]

The chown problem I mentioned in the last paragraph of
<http://lists.gnu.org/archive/html/bug-coreutils/2005-12/msg00264.html>
still remains.  My initial reaction is to do something for chown that
is similar to what I just installed fro chmod; this would prefer
lchown to chown.  lchown is not quite as good as the fchown approach
in some respects, but it's better in others -- e.g., it avoids side
effects on special files like fifos and tape drives -- and it does
have the advantage of being longstanding practice.

While looking at the code I noticed another problem with the
fchown-based approach in coreutils CVS.  Currently, the code fails if
you lack read or write access to a file that you want to chown or
chgrp.  In the following example, coreutils CVS chown incorrectly
fails, whereas coreutils 5.2.1 chown correctly succeeds:

   $ touch /tmp/foo
   $ chmod 111 /tmp/foo
   $ ls -l /tmp/foo
   ---x--x--x 1 eggert eggert 0 Jan  2 00:09 /tmp/foo
   $ groups
   eggert dialout cdrom floppy audio video plugdev
   $ ./chown --from=:eggert -c :cdrom /tmp/foo
   ./chown: changing group of `/tmp/foo': Permission denied
   $ /bin/chown --from=:eggert -c :cdrom /tmp/foo
   changed ownership of `/tmp/foo' to :cdrom
   $ ls -l /tmp/foo
   ---x--x--x 1 eggert cdrom 0 Jan  2 00:09 /tmp/foo
   $ /bin/chown --version | sed 1q
   chown (coreutils) 5.2.1
   $ ./chown --version | sed 1q
   chown (GNU coreutils) 6.0-cvs

Switching to an lchown-based approach would fix this problem too.