bug#14024: Test failure in coreutils 8.13

[Ellis N. Thomas]

Pádraig,

        Following your points below about groups, I checked the owner/groups
of the various directories where I variously ran and repeated the  
coreutils tests
and did sequences for you like:

echo test > a
/usr/local/bin/install -Cv -m0644 a b
/usr/local/bin/stat a b
/usr/local/bin/install -Cv -m0644 a b

	I now see why my latest ones gave different results from the earlier  
ones,
and why the earlier ones did not seem to match the reported test  
failures.

	The earlier sequences were run in my own directory ~/tmp, so that the  
files
a and b were in a temporary directory.  However, the latest ones, that  
responded
with:
        removed 'b'
        'a' -> 'b'
were run where I had just rerun the
        "make check TESTS=tests/install/install-C.sh VERBOSE=yes SUBDIRS=."
which is /Gnu/coreutils/coreutils-8.21.  This dir hierarchy is not g+s  
to a group other than
my own, but does have group values that are not my own.  There do not  
seem to be ACLs
on these directories, but some have "extended attributes".

	I was not able to use getfacl on this system, but ls -e shows ACLs,  
and if the file or
directory has extended security information, the permissions field  
printed by the -l option
is followed by a '+' character (from man ls).

	My user on this iMac has Administrator privileges, which in practice  
means that
it is in group 'admin', and several other groups.  These users have  
the ability to create
"top-level" directories, like /Gnu.  This ability seems to arise  
because '/' has group
'admin', and the created directories do too, but are owned by the  
creator (the result
seems to be the same whether the directory is created by a Unix mkdir,  
or using the
Mac gui Finder application):

ls -Ald@ / /Gnu /Gnu/coreutils/ /Gnu/coreutils/coreutils-8.21
drwxrwxr-t  45 root          admin  1598 Apr 12 20:40 /
drwxrwxr-x  12 admin         admin   408 Feb 16 12:12 /Gnu
drwxr-xr-x  11 ellisnthomas  admin   374 Apr 12 20:42 /Gnu/coreutils/
drwxr-xr-x@ 57 ellisnthomas  admin  1938 Apr 11 15:27 /Gnu/coreutils/ 
coreutils-8.21
        com.apple.quarantine      78

	(I am not clear what this extended attribute does.  It seems related  
to Mac regarding
downloaded files with suspicion - the directory tree was originally  
extracted from
/Gnu/coreutils/coreutils-8.21.tar.gz)

        In my own directories, the group is staff:
ls -Ald ~
drwxr-xr-x+ 53 ellisnthomas  staff  1802 Apr 12 20:04 /Users/ 
ellisnthomas

ls -Alde ~/tmp/ drwxr-xr-x 8 ellisnthomas staff 272 Mar 27 20:59 / 
Users/ellisnthomas/tmp/

        To clarify the gids and uids I checked the groups, using dscacheutil
(man says "dscacheutil does various operations against the Directory  
Service cache
     including gathering statistics, initiating lookups, inspection,  
cache
     flush, etc.  This tool replaces most of the functionality of the  
lookupd
     tool previously available
 Darwin   Jan 14, 2007")

	One aspect here is that there is both a user 'admin' and a group  
'admin'.
It seems that user admin created the directory /Gnu, but user  
ellisnthomas
created /Gnu/coreutils/ later.

dscacheutil -q group -a name admin
name: admin
password: *
gid: 80
users: root ellisnthomas admin

dscacheutil -q group -a gid 20
name: staff
password: *
gid: 20
users: root ellisnthomas admin susanthomas

dscacheutil -q user -a name ellisnthomas
name: ellisnthomas
password: ********
uid: 501
gid: 20
dir: /Users/ellisnthomas
shell: /bin/bash
gecos: Ellis Thomas

dscacheutil -q user -a name admin
name: admin
password: ********
uid: 502
gid: 20
dir: /Users/admin
shell: /bin/bash
gecos: ExtraLeveLInSoftware

        The usage of getfacl is not possible, but tried ls -e.
type -a getfacl
bash: type: getfacl: not found

ls -Alde /Gnu/coreutils/coreutils-8.21
drwxr-xr-x@ 57 ellisnthomas  admin  1938 Apr 11 15:27 /Gnu/coreutils/ 
coreutils-8.21

ls -Alde /Gnu/
drwxrwxr-x  12 admin  admin  408 Feb 16 12:12 /Gnu/

ls -Alde ~/tmp/
drwxr-xr-x  8 ellisnthomas  staff  272 Mar 27 20:59 /Users/ 
ellisnthomas/tmp/

ls -Alde ~
drwxr-xr-x+ 53 ellisnthomas  staff  1802 Apr 12 09:01 /Users/ 
ellisnthomas
 0: group:everyone deny delete

        This seems to be the only one with an ACL.

        So in summary it seems that install is seeing the two different groups:
'admin' in the existing 'a' file, and expecting to set 'staff' in the  
new 'b' file
as you suggested, but because the parent directory already has 'admin'
without either the g+s or ACL involvement.

        It seems it is now explained, anyway.

        Ellis

On 12 Apr 2013, at 02:37, Pádraig Brady wrote:

> Great thanks.
>
> That shows that the gid of the files is 80, which I presume is
> separate to your gid. That can happen if you're in a dir hierarchy
> that's g+s to a group other than your own.
> Hmm I see the test already detects this case and skips the test
> with skip_if_setgid_(). Perhaps POSIX default ACLs or something are
> setting this admin group for you?
> Can you confirm that the dir isn't setgid by showing the output of:
> /usr/local/bin/stat .
> Can you display ACLs with `getfacl .` ?