bug#14024: Test failure in coreutils 8.13

[Pádraig Brady]

On 04/11/2013 03:30 PM, Ellis N. Thomas wrote:
> Pádraig,
> 
>     The Gnu "bug-coreutils Archives" does not seem to have linked
> my reply message of April 10, 2013, and your reply as below, to our
> previous messages for bug#14024 on and before March 27, 2013.
> 
>     See my message of 27 March 2013 21:08:09 GMT (in archive as 17:08)
> for details about the file system.
> 
>     I have repeated the echo... sequence below (remember this is now 8.21
> not 8.13 following your message of Fri, 22 March 2013 12:45:56 GMT and my
> response of Wed, 27 March 2013 11:47:30 GMT).
> 
>  >echo test > a
>  >/usr/local/bin/install -Cv -m0644 a b
> 'a' -> 'b'
>  >/usr/local/bin/stat a b
>   File: 'a'
>   Size: 5               Blocks: 8          IO Block: 4096   regular file
> Device: e000002h/234881026d     Inode: 6260011     Links: 1
> Access: (0644/-rw-r--r--)  Uid: (  501/ellisnthomas)   Gid: (   80/   admin)
> Access: 2013-04-11 15:08:12.000000000 +0100
> Modify: 2013-04-11 15:07:52.000000000 +0100
> Change: 2013-04-11 15:07:52.000000000 +0100
>  Birth: 2013-04-11 15:07:52.000000000 +0100
>   File: 'b'
>   Size: 5               Blocks: 8          IO Block: 4096   regular file
> Device: e000002h/234881026d     Inode: 6260013     Links: 1
> Access: (0644/-rw-r--r--)  Uid: (  501/ellisnthomas)   Gid: (   80/   admin)
> Access: 2013-04-11 15:08:12.000000000 +0100
> Modify: 2013-04-11 15:08:12.000000000 +0100
> Change: 2013-04-11 15:08:12.000000000 +0100
>  Birth: 2013-04-11 15:08:12.000000000 +0100
>  >/usr/local/bin/install -Cv -m0644 a b
> removed 'b'
> 'a' -> 'b'

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 .` ?

Anyway it highlights a shortcoming in the test,
and a possible shortcoming in install(1) itself.

So let's setup such a setgid directory for illustration:

$ mkdir -m g+s ti && cd ti
$ chgrp wheel .
$ touch a
$ install -Cv -m0664 a b
`a' -> `b'
$ ls -l
total 0
-rw-rw-r--. 1 padraig wheel 0 Apr 12 02:08 a
-rw-rw-r--. 1 padraig wheel 0 Apr 12 02:08 b

So we see above that the files are the same,
so shouldn't need a subsequent install, but:

$ install -Cv -m0664 a b
removed `b'
`a' -> `b'

That's because install(1) sees that b does not have our gid
and assumes that the gid of b would be set to our gid if we
did install, and so does the redundant operation.

However switching things around, illustrates a possible
problem with this logic in install(1). If we set the dest
file to our group id, then install(1) assumes that that's
what would be used for the file and does nothing, when it
probably should to ensure that the group is reset?

$ chgrp $USER b
$ install -Cv -m0664 a b
$ ls -l
total 0
-rw-rw-r--. 1 padraig wheel   0 Apr 12 02:08 a
-rw-rw-r--. 1 padraig padraig 0 Apr 12 02:08 b

Now install couldn't really infer all the combinations
of auto metadata settings that might occur on file creation,
so we should probably put a warning with --compare in the
texinfo to say it makes assumptions about default
users and permissions which may be incorect in the
presence of POSIX default ACLs or setgid directories
for example.

thanks,
Pádraig.