bug#14024: Test failure in coreutils 8.13

[Pádraig Brady]

On 04/12/2013 10:30 PM, Ellis N. Thomas wrote:
> 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 .` ?
>
> 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.

Thanks for the detail.
I'll probably work around that test failure with the attached.

thanks,
Pádraig.

osx-install-C-skip.patch
Description: Text Data