On 05/12/2024 21:56, Paul Eggert wrote:
On 2024-12-04 09:10, Ioanna Alifieraki wrote:
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.
That's not what I expect, any more than I'd expect 'stat' to fail on the
directory. A directory's permissions should affect only accesses to its
data, not to its metadata.
Do you observe similar problems on file systems other than NFS? If not,
this sounds like an NFS bug. Possibly coreutils should work around the
bug, but first it'd be helpful to know exactly how the bug works. For
example, what permissions does NFS require on a directory before it
allows listxattr to succeed? What platform are you running (OS, version,
etc.)?
I can repo on nfs.
I setup an nfs server on localhost on Fedora 41 following the instructions at:
https://reintech.io/blog/configuring-nfs-server-fedora-38
Seemingly xattrs are supported on NFS since nfs 4.2 and kernel 5.9
(I'm running 6.12.6-200.fc41.x86_64 here).
In my testing:
You need write permission to set xattrs on local or nfs.
You need read permission to get xattrs on local or nfs.
You need read permission to list xattrs on nfs.
You need no permissions to list xattrs locally.
I tested the listing with `ls -l` and `attr -l`.
The EACCES is returned from both llistxattr and listxattr.
So this looks like an inconsistency in nfs,
but also a common scenario I expect.
So I would think we should ignore the EACCES from listxattr().
For ls at least, any real permission issues would be diagnosed with stat() etc.
cheers,
Pádraig
