[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: coreutils-5.2.1: test failure - chgrp/posix-H
From: |
Jim Meyering |
Subject: |
Re: coreutils-5.2.1: test failure - chgrp/posix-H |
Date: |
Sat, 01 May 2004 08:52:45 +0200 |
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)