GNU bug report logs - #74692
ls -la unexpected output on NFS shares, possibly due to listxattr in gnulib

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 74692 in the body.
You can then email your comments to 74692 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>
To: bug-coreutils <at> gnu.org
Subject: ls -la unexpected output on NFS shares,
 possibly due to listxattr in gnulib
Date: Wed, 4 Dec 2024 19:10:59 +0200

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

Message #8 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>
Cc: 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Thu, 5 Dec 2024 13:56:00 -0800

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 could not reproduce the problem on a non-NFS file system with 
bleeding-edge coreutils (commit 
fd01fc8075a0df4e9036fdb962b589e60c134e26) on Fedora 40 x86-64. I tried 
on ext4 as follows:

  mkdir d d/e
  setfacl -m u:root:r d/e
  chmod 0 d/e
  LC_ALL=C strace -o tr ls -la d

This worked as expected, producing this output:

  total 32
  drwxrwxr-x.  3 eggert eggert  4096 Dec  5 13:47 .
  drwxr-xr-x. 10 eggert eggert 20480 Dec  5 13:47 ..
  d---------+  2 eggert eggert  4096 Dec  5 13:47 e

with no diagnostics. Inspecting the 'tr' file, I found the following. 
Notice that the call listxattr("d/e", ...) succeeds even though I lack 
all permissions to d/e. Could you try something similar on your platform?

...
openat(AT_FDCWD, "d", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3
fstat(3, {st_mode=S_IFDIR|0775, st_size=4096, ...}) = 0
getdents64(3, 0x5621e6b8a740 /* 3 entries */, 32768) = 72
statx(AT_FDCWD, "d/e", 
AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, 
STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, 
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFDIR|000, stx_size=4096, ...}) = 0
lgetxattr("d/e", "security.selinux", 
"unconfined_u:object_r:user_home_"..., 255) = 37
listxattr("d/e", "security.selinux\0system.posix_ac"..., 152) = 41
statx(AT_FDCWD, "d/..", 
AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, 
STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, 
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFDIR|0755, stx_size=20480, ...}) = 0
lgetxattr("d/..", "security.selinux", 
"unconfined_u:object_r:user_home_"..., 255) = 37
listxattr("d/..", "security.selinux\0", 152) = 17
statx(AT_FDCWD, "d/.", 
AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW|AT_NO_AUTOMOUNT, 
STATX_MODE|STATX_NLINK|STATX_UID|STATX_GID|STATX_MTIME|STATX_SIZE, 
{stx_mask=STATX_BASIC_STATS|STATX_MNT_ID, stx_attributes=0, 
stx_mode=S_IFDIR|0775, stx_size=4096, ...}) = 0
lgetxattr("d/.", "security.selinux", 
"unconfined_u:object_r:user_home_"..., 255) = 37
listxattr("d/.", "security.selinux\0", 152) = 17
getdents64(3, 0x5621e6b8a740 /* 0 entries */, 32768) = 0
close(3)                                = 0
fstat(1, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0x1), ...}) = 0
write(1, "total 32\n", 9)               = 9
...

Message #11 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>
Cc: 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Wed, 8 Jan 2025 14:24:48 +0000

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

Message #14 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Wed, 8 Jan 2025 11:41:25 -0800

[Message part 1 (text/plain, inline)]

On 2025-01-08 06:24, Pádraig Brady wrote:
> The EACCES is returned from both llistxattr and listxattr.

Is flistxattr the same?


> You need read permission to get xattrs on local or nfs. 

Isn't it more complicated than that, for local file systems? Here's what 
I observe on Fedora 41 with a local ext4 file system. Sometimes I need 
read permission, sometimes I don't. (Is any of this stuff documented?)

  $ touch ghijkl
  $ setfattr -n user.foo -v bar ghijkl
  $ chmod 0 ghijkl
  $ strace -o tr ls -l ghijkl
----------. 1 eggert eggert 0 Jan  8 11:27 ghijkl
  $ grep xattr tr
  llistxattr("ghijkl", "security.selinux\0user.foo\0", 152) = 26
  lgetxattr("ghijkl", "security.selinux", 
"unconfined_u:object_r:user_home_"..., 255) = 37
  $ strace -o tr2 getfattr -n security.selinux ghijkl
  # file: ghijkl
  security.selinux="unconfined_u:object_r:user_home_t:s0"

  $ grep xattr tr2
  getxattr("ghijkl", "security.selinux", NULL, 0) = 37
  getxattr("ghijkl", "security.selinux", 
"unconfined_u:object_r:user_home_"..., 256) = 37


> So this looks like an inconsistency in nfs,
> but also a common scenario I expect.

Yes, unfortunately.


> 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.

Ignoring EACCES doesn't sound right. This situation differs from the 
other ones noted in lib/acl-errno-valid.c. In those situations, a file 
system or kernel issues a weird errno value when ACLs aren't supported, 
and so it's appropriate to treat those errno values as if they were ENOTSUP.

Here, if I understand things correctly, the file system supports ACLs 
but it doesn't want to give you the information. That's something I'd 
want to know about if I am the 'ls' user.

How about something like the attached patch instead? It's incomplete 
(needs doc) and untested but I hope it gives you the basic idea, which 
is to put '?' in the ACL column when you lack permissions to find out 
whether ACLs are present.

[acl.diff (text/x-patch, attachment)]

Message #19 received at 74692-done <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 74692-done <at> debbugs.gnu.org,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Wed, 8 Jan 2025 22:02:33 +0000

[Message part 1 (text/plain, inline)]

On 08/01/2025 19:41, Paul Eggert wrote:
> On 2025-01-08 06:24, Pádraig Brady wrote:
>> The EACCES is returned from both llistxattr and listxattr.
> 
> Is flistxattr the same?
> 
> 
>> You need read permission to get xattrs on local or nfs.
> 
> Isn't it more complicated than that, for local file systems? Here's what
> I observe on Fedora 41 with a local ext4 file system. Sometimes I need
> read permission, sometimes I don't. (Is any of this stuff documented?)
> 
>     $ touch ghijkl
>     $ setfattr -n user.foo -v bar ghijkl
>     $ chmod 0 ghijkl
>     $ strace -o tr ls -l ghijkl
> ----------. 1 eggert eggert 0 Jan  8 11:27 ghijkl
>     $ grep xattr tr
>     llistxattr("ghijkl", "security.selinux\0user.foo\0", 152) = 26
>     lgetxattr("ghijkl", "security.selinux",
> "unconfined_u:object_r:user_home_"..., 255) = 37
>     $ strace -o tr2 getfattr -n security.selinux ghijkl
>     # file: ghijkl
>     security.selinux="unconfined_u:object_r:user_home_t:s0"
> 
>     $ grep xattr tr2
>     getxattr("ghijkl", "security.selinux", NULL, 0) = 37
>     getxattr("ghijkl", "security.selinux",
> "unconfined_u:object_r:user_home_"..., 256) = 37

Indeed the GET permissions are more nuanced,
and seem to vary based on the namespace.
`getfattr` seems to infer the namespace to use automatically,
whereas the `attr` tool I was using requires more manual specifications:

~$ chmod 0 nfs/file

~$ strace -e trace=/.*xattr.* attr -g security.selinux nfs/file
lgetxattr("nfs/file", "user.security.selinux", 0x55ecedbfd430, 65536) = -1 EACCES (Permission denied)

~$ strace -e trace=/.*xattr.* getfattr -n security.selinux nfs/file
getxattr("nfs/file", "security.selinux", NULL, 0) = 37
getxattr("nfs/file", "security.selinux", "unconfined_u:object_r:user_home_"..., 256) = 37

~$ strace -e trace=/.*xattr.* attr -S -g selinux nfs/file
lgetxattr("nfs/file", "security.selinux", "unconfined_u:object_r:user_home_"..., 65536) = 37

I.E. locally at least the user permissions are applied for GET only for the "user." namespace.

>> So this looks like an inconsistency in nfs,
>> but also a common scenario I expect.
> 
> Yes, unfortunately.
> 
> 
>> 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.
> 
> Ignoring EACCES doesn't sound right. This situation differs from the
> other ones noted in lib/acl-errno-valid.c. In those situations, a file
> system or kernel issues a weird errno value when ACLs aren't supported,
> and so it's appropriate to treat those errno values as if they were ENOTSUP.
> 
> Here, if I understand things correctly, the file system supports ACLs
> but it doesn't want to give you the information. That's something I'd
> want to know about if I am the 'ls' user.
> 
> How about something like the attached patch instead? It's incomplete
> (needs doc) and untested but I hope it gives you the basic idea, which
> is to put '?' in the ACL column when you lack permissions to find out
> whether ACLs are present.

Yes that does sound better than ignoring that info.
We would still output '?' whereas coreutils < 9.3 did not,
but that would be much less intrusive and contained to the files in question.

So ls now does:

  $ src/ls -l /mnt/nfs
  ----------? 1 padraig padraig 0 Jan  8 20:42 file

The attached does that and adds docs.

Marking this as done.

cheers,
Pádraig

[ls-nfs-eacces.patch (text/x-patch, attachment)]

Message #22 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Wed, 8 Jan 2025 20:55:54 -0800

Thanks, but is this part of the change needed?

> +  else if (f->acl_type == ACL_T_UNKNOWN)
> +    modebuf[10] = '?';

I thought modebuf[10] was already '?' at that point.

Message #25 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: linux-nfs <at> vger.kernel.org,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Thu, 9 Jan 2025 13:29:22 +0000

I've CC'd linux-nfs in case anyone there has some insight
as to why listxattr() is more restrictive on NFS than locally,
returning EACCES for files without read access. Details below...

On 09/01/2025 04:55, Paul Eggert wrote:
> Thanks, but is this part of the change needed?
> 
>> +  else if (f->acl_type == ACL_T_UNKNOWN)
>> +    modebuf[10] = '?';
> 
> I thought modebuf[10] was already '?' at that point.

Only if the stat() failed, which is not the case here.

Note it's worth mentioning that over NFS with unreadable files
you can GET the security.selinux xattr, but you can't LIST any xattrs:

  $ strace -e trace=/.*xattr.* attr -S -g selinux /mnt/nfs/file
  lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0", 65536) = 27
  Attribute "selinux" had a 27 byte value for /mnt/nfs/file:
  system_u:object_r:nfs_t:s0
  +++ exited with 0 +++

  $ strace -e trace=/.*xattr.* attr -S -l /mnt/nfs/file
  llistxattr("/mnt/nfs/file", 0x7ffc92de48a0, 65536) = -1 EACCES (Permission denied)
  attr_list: Permission denied
  Could not list /mnt/nfs/file

Also there was a change since coreutils v9.5 where we don't call the GET,
whereas coreutils 9.5 did call lgetxattr() and thus showed the correct (.) flag
(albeit with the problematic warning):

  $ strace -e trace=/.*xattr.* src/ls -l /mnt/nfs/file
  llistxattr("/mnt/nfs/file", 0x7ffe1e5b7b6c, 152) = -1 EACCES (Permission denied)
  --w-------? 1 padraig padraig 0 Jan  8 20:42 /mnt/nfs/file
  +++ exited with 0 +++

  $ strace -e trace=/.*xattr.* ls-v9.5 -l /mnt/nfs/file
  lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = 27
  listxattr("/mnt/nfs/file", 0x7ffd58023810, 152) = -1 EACCES (Permission denied)
  ls: /mnt/nfs/file: Permission denied
  --w-------. 1 padraig padraig 0 Jan  8 20:42 /mnt/nfs/file
  +++ exited with 0 +++

So perhaps we should also always call lgetxattr("security.selinux"),
or at least fall back to that upon EACCES from listxattr() ?

cheers,
Pádraig

Message #28 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: linux-nfs <at> vger.kernel.org, Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Thu, 9 Jan 2025 20:46:22 -0800

[Message part 1 (text/plain, inline)]

On 2025-01-09 05:29, Pádraig Brady wrote:

> over NFS with unreadable files
> you can GET the security.selinux xattr, but you can't LIST any xattrs:

Ouch again....


> Also there was a change since coreutils v9.5 where we don't call the GET,

Yes, that is for efficiency in the common case where the file has no 
attributes. In that case, ls (via file_has_aclinfo) needs only one 
llistxattr call and can skip the other syscalls.


> So perhaps we should also always call lgetxattr("security.selinux"),
> or at least fall back to that upon EACCES from listxattr() ?

The latter sounds better, given the efficiency concerns. Also, come to 
think of it, E2BIG is in the same category as EACCES.

I installed the attached into Gnulib and propagated it into coreutils; 
please give it a try.

[0001-file-has-acl-port-to-Linux-6.12-NFS-listxattr.patch (text/x-patch, attachment)]

Message #31 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Fri, 10 Jan 2025 14:48:48 +0000

On 10/01/2025 04:46, Paul Eggert wrote:
> On 2025-01-09 05:29, Pádraig Brady wrote:
> 
>> over NFS with unreadable files
>> you can GET the security.selinux xattr, but you can't LIST any xattrs:
> 
> Ouch again....
> 
> 
>> Also there was a change since coreutils v9.5 where we don't call the GET,
> 
> Yes, that is for efficiency in the common case where the file has no
> attributes. In that case, ls (via file_has_aclinfo) needs only one
> llistxattr call and can skip the other syscalls.
> 
> 
>> So perhaps we should also always call lgetxattr("security.selinux"),
>> or at least fall back to that upon EACCES from listxattr() ?
> 
> The latter sounds better, given the efficiency concerns. Also, come to
> think of it, E2BIG is in the same category as EACCES.
> 
> I installed the attached into Gnulib and propagated it into coreutils;
> please give it a try.

Yes, with that gnulib patch it is now indicating the security context:

$ strace -e trace=/.*xattr.* src/ls -l /mnt/nfs/file
llistxattr("/mnt/nfs/file", 0x7ffd73a9694c, 152) = -1 EACCES (Permission denied)
lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = 27
ls: /mnt/nfs/file: Permission denied
--w-------. 1 padraig padraig 0 Jan  8 20:42 /mnt/nfs/file
+++ exited with 0 +++

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!

Pádraig

Message #34 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Sat, 11 Jan 2025 00:37:34 -0800

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?

Message #37 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Sat, 11 Jan 2025 13:44:50 +0000

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

Message #40 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Sat, 11 Jan 2025 16:48:16 +0000

[Message part 1 (text/plain, inline)]

On 11/01/2025 13:44, Pádraig Brady wrote:
> 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.

...

> 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.

The attached gnulib patch does that.

With a file without read access we get:

$ strace -e trace=/.*xattr.* ~/git/coreutils/src/ls -l /mnt/nfs/file
llistxattr("/mnt/nfs/file", 0x7ffc615bddcc, 152) = -1 EACCES (Permission denied)
lgetxattr("/mnt/nfs/file", "security.selinux", "system_u:object_r:nfs_t:s0", 255) = 27
lgetxattr("/mnt/nfs/file", "system.nfs4_acl", NULL, 0) = 128
lgetxattr("/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

$ chmod u+r file  # Restore normal fast case

$ strace -e trace=/.*xattr.* ~/git/coreutils/src/ls -l /mnt/nfs/file
llistxattr("/mnt/nfs/file", "system.nfs4_acl\0user.attr_foo\0", 152) = 30
lgetxattr("/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


cheers,
Pádraig

[gnulib-nfsv4-acl.patch (text/x-patch, attachment)]

Message #43 received at 74692 <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: Gnulib bugs <bug-gnulib <at> gnu.org>,
 Ioanna Alifieraki <ioanna-maria.alifieraki <at> canonical.com>,
 74692 <at> debbugs.gnu.org
Subject: Re: bug#74692: ls -la unexpected output on NFS shares, possibly due
 to listxattr in gnulib
Date: Sat, 11 Jan 2025 10:25:15 -0800

On 2025-01-11 08:48, Pádraig Brady wrote:
> The attached gnulib patch does that.

Thanks for fixing that.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.