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