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
--- End Message ---