GNU bug report logs -
#21130
test fail: 'tests/ls/stat-failed'
Previous Next
Full log
View this message in rfc822 format
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
This bug report was last modified 9 years and 187 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.