Re: coreutils-5.2.1: test failure - chgrp/posix-H

[Jim Meyering]

Michael Deutschmann <address@hidden> wrote:
...
> Actually, it's just that linux-2.0.40 has only one chown syscall, which
> has always (on i386) had "lchown()" semantics.  It looks like the glibc
> developers have, ( uncharacteristically :) ) opted against bloat and
> decided to use that syscall as a direct replacement for regular chown(),
> instead of emulating it using readlink.

Thanks for investigating.

> I patched 2.0.40 to implement the second non-lchown() chown syscall into
> 2.0.40, and all tests pass under the modified kernel.
>
> So it looks like there are three paths out:
>  1. Declare that it's okay for chgrp -H to change the link ownership only
>     (whether this option is available depends on what the standards say.)

This is not an option.
POSIX is clear: chgrp -HR must not change permissions of the symlink.

>  2. Get my kernel mod adopted into 2.0.41, then define Linux >= 2.0.41 as
>     a coreutils prerequisite.
>  3. Alter coreutils to defend against the possibility that chown() is
>     really lchown().

I might go for #3.
Here's a comment (albeit temporary) that I've just checked in.
The only trick will be the autoconf `run' test:
If anyone knows how to test chown(2) -- to see if it dereferences symlinks --
when called by a non-root user with only one group, please let me know.

Index: src/chown-core.c
===================================================================
RCS file: /fetish/cu/src/chown-core.c,v
retrieving revision 1.19
diff -u -p -r1.19 chown-core.c
--- src/chown-core.c    27 Apr 2004 15:01:12 -0000      1.19
+++ src/chown-core.c    1 May 2004 06:45:23 -0000
@@ -226,6 +226,16 @@ change_file_owner (FTS *fts, FTSENT *ent
                  /* Applying chown to a symlink and expecting it to affect
                     the referent is not portable.  So instead, open the
                     file and use fchown on the resulting descriptor.  */
+                 /* FIXME: but on some systems (e.g. Linux-2.1.81 and newer),
+                    using chown is much better, since it *does* follow
+                    symlinks, and the open/fchown approach fails when
+                    the file is not readable.  This looks like a fine case
+                    for another chown wrapper.  In any case, this code can
+                    clobber errno, so fix it or remove it.
+                    Related: with a proper autoconf test -- is this possible,
+                    without root permissions or a guarantee of more than
+                    one group? -- the lchown wrapper may just end up
+                    calling chown on some systems.  */
                  int fd = open (file, O_RDONLY | O_NONBLOCK | O_NOCTTY);
                  fail = (fd == -1 ? 1 : fchown (fd, new_uid, new_gid));
                  if (fd != -1)