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



Reply via email to