bug#21130: test fail: 'tests/ls/stat-failed'

[Pádraig Brady]

On 25/07/15 06:07, Pádraig Brady wrote:
> On 24/07/15 22:46, Assaf Gordon wrote:
>> Hello,
>>
>> checking coreutils 8.24, running on NFS, the test 'ls/stat-failed' fails 
>> (log attached).
>>
>> If I understand correctly,
>> The test creates a symlink to a directory then removes execute permissions:
>>     mkdir d
>>     ln -s / d/s
>>     chmod 600 d
>>
>> Then tries to dereference it:
>>      $ ls -Log d
>>      ls: cannot access d/s: Permission denied
>>      total 0
>>      d????????? ? ?            ? s
>>
>> The test expect 's' to have 'l' type, on my system it is 'd'.
>>
>> The attached patch avoids the failure, though I don't know if this is 
>> correct or not (perhaps this failure should not be avoided?).
>>
>> The system is:
>>      $ uname -a
>>      Linux XXX 2.6.32-431.el6.x86_64 #1 SMP Fri Nov 22 03:15:09 UTC 2013 
>> x86_64 x86_64 x86_64 GNU/Linux
>>      $ gcc --version
>>       gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
>>
>> The file system is NFS.
> 
> Interesting. Is the NFS server RHEL6 too?
> 
> With normal perms on 'd':
>  On ext4 I get ^d
>   With syscalls being:
>     getdents(3, /* 3 entries */, 32768)     = 72
>     stat("d/s", {st_mode=S_IFDIR|0555, st_size=4096, ...}) = 0
> 
> With -x perms on 'd':
>  On nfsv4 here I get ^?
>  On ext4 I get ^l
>   With syscalls being:
>     getdents(3, /* 3 entries */, 32768)     = 72
>     stat("d/s", 0x7f634b9594a0)             = -1 EACCES (Permission denied)
> 
> So it seems you're getting next->d_type==DR_DIR in that case?
> That would be wrong, but a system issue rather than a problem in ls I think.
> 
> The test adjustment looks OK but would benefit from a comment
> stating the first letter represents d_type and that on buggy
> systems may be 'd'.

Another possibility might be that the chmod(1) and stat(2) are racy
thus allowing the stat() to succeed? If that was the case then
a stat d/s && skip_ ... would avoid the false failure?