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

[Pádraig Brady]

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'.

thanks!
Pádraig