Hi,
I’m writing to report unexpected behavior in the output of ls on NFS
shares, which appears to be related to the listxattr in gnulib.
When a user lacks permissions to access certain directories on an NFS
share, ls -la produces "Permission denied" errors for those directories
and then the output of the command as expected.
For example:
$ ls -la /opt/example/
ls: /opt/example/test: Permission denied
ls: /opt/example/ubuntu: Permission denied
total 20
drwxr-xr-x 5 root root 4096 Nov 7 19:21 .
drwxr-xr-x 3 root root 4096 Nov 7 19:26 ..
drwxr-x--- 4 jo jo 4096 Nov 7 13:35 jo
drwxr-x--- 2 1002 1002 4096 Nov 7 19:21 test
drwxr-x--- 2 ubuntu ubuntu 4096 Nov 7 19:21 ubuntu
The issue seems to have been introduced by commit b851a965da62 [1],
which added listxattr.
When ls -la is run on NFS shares, get_aclinfo() in gnulib is eventually
invoked. This calls listxattr, which, as expected, returns -1 and sets
errno when the user lacks permissions for a directory.
The error is subsequently printed by gobble_file() as follows:
int n = file_has_aclinfo_cache (full_name, f, &ai, aclinfo_flags);
...
if (format == long_format && n < 0)
error (0, ai.u.err, "%s", quotef (full_name));
file_has_aclinfo_cache() returns -1, causing the "Permission denied"
error to be displayed for directories the user cannot access.
I am able to reproduce this behaviour with latest coreutils and gnulib.
This does not happen with coreutils 9.3 and earlier.
Best,
Jo
[1]
https://git.savannah.gnu.org/gitweb/?p=gnulib.git;a=commit;h=b851a965da62cd858d71b2e5a7261a211f00b297
