On 11/01/2025 08:37, Paul Eggert wrote:
On 2025-01-10 06:48, Pádraig Brady wrote:
With the previously discussed ls patch included, we also suppress the error
(while indicating the obtainable security context):
$ src/ls -l /mnt/nfs
total 0
--w-------. 1 padraig padraig 0 Jan 8 20:42 file
I'll push that ls patch now.
Thanks, but I'm not sure that resolves all the issues that can occur
when [l]listxattr returns -1 with errno==EACCES or errno==E2BIG. In this
case we've fixed the bug where the file has a security context but no
NFSv4 or POSIX ACLs. But what if the file has those ACLs?
True.
Note POSIX ACLs don't seem to be supported on my NFS setup at least:
$ setfacl -m user:nobody:rwx file # set local POSIX ACL
$ getfacl file
# file: file
# owner: padraig
# group: padraig
user::-w-
user:nobody:rwx
group::---
mask::rwx
other::---
As going back to an older ls that didn't use listxattr(), still gives
EOPNOTSUPP.
$ strace -e trace=/.*xattr.* ~/coreutils-9.0/src/ls -l /mnt/nfs/file
lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0",
255) = 27
getxattr("/mnt/nfs/file", "system.posix_acl_access", NULL, 0) = -1 EOPNOTSUPP
--w-rwx---. 1 padraig padraig 0 Jan 8 20:42 /mnt/nfs/file
That is more correct in that it does the GET, but the result is not practically
different.
Reading about transferring of POSIX ACLs on NFS in the following explains the
issue somewhat:
https://www.usenix.org/legacy/publications/library/proceedings/usenix03/tech/freenix03/full_papers/gruenbacher/gruenbacher_html/main.html
As for NFSv4 ACLs, which we support in coreutils-9.3 at least ...
$ strace -e trace=/.*xattr.* nfs4_getfacl /mnt/nfs/file
getxattr("/mnt/nfs/file", "system.nfs4_acl", NULL, 0) = 128
getxattr("/mnt/nfs/file", "system.nfs4_acl",
"\0\0\0\5\0\0\0\1\0\0\0\0\0\0\0!\0\0\0\6OWNER@\0\0\0\0\0", 128) = 128
# file: /mnt/nfs/file
D::OWNER@:rx
A::OWNER@:watTcCy
A::65534:rwaxtcy
A::GROUP@:tcy
A::EVERYONE@:tcy
So yes we can read these practically without having read permission on the file,
and yes ls did indicate the '+' flag in this case:
$ strace -e trace=/.*xattr.* ~/coreutils-9.3/src/ls -l /mnt/nfs/file
lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0",
255) = 27
getxattr("/mnt/nfs/file", "system.posix_acl_access", NULL, 0) = -1 EOPNOTSUPP
(Operation not supported)
getxattr("/mnt/nfs/file", "system.nfs4_acl",
"\0\0\0\5\0\0\0\1\0\0\0\0\0\0\0!\0\0\0\6OWNER@\0\0\0\0\0", 152) = 128
--w-rwx---+ 1 padraig padraig 0 Jan 8 20:42 /mnt/nfs/file
To confirm, the listxattr() is still returning EACCES with the above permission
set:
$ strace -e trace=/.*xattr.* ~/git/coreutils/src/ls -l /mnt/nfs/file
llistxattr("/mnt/nfs/file", 0x7ffd8f2d4a5c, 152) = -1 EACCES (Permission
denied)
lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0",
255) = 27
--w-rwx---. 1 padraig padraig 0 Jan 8 20:42 /mnt/nfs/file
So I guess we need to treat EACCES from listxattr()
as meaning any significant xattr is present, but we should GET to confirm.
This shouldn't be too onerous perf wise at least given it's only for
files without read access.
We should also notify linux nfs folks as it seems like an issue
that listxattr() is returning EACCES at all.
cheers,
Pádraig
