GNU bug report logs - #77597
coreutils 9.6: regression in handling security.selinux attribute for ls(1)

Previous Next

To reply to this bug, email your comments to 77597 AT debbugs.gnu.org.

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

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

From: "Rahul Sandhu" <nvraxn <at> gmail.com>
To: <bug-coreutils <at> gnu.org>
Cc: eggert <at> cs.ucla.edu
Subject: coreutils 9.6: regression in handling security.selinux attribute
 for ls(1)
Date: Sun, 06 Apr 2025 02:49:32 +0100

Hey,

coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware
builds. `ls -Z` fails to obtain the security context for certain
filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with
refpolicy:

rsandhu <at> graphite ~ $ ls -alZ /run/ | grep '?'
drwxr-xr-x   3 root     root     ?                                               60 Apr  5 16:38 credentials
drwxr-xr-x   3 root     root     ?                                               80 Apr  2 16:30 initramfs
drwxr-xr-x   2 root     root     ?                                               40 Apr  2 16:23 modprobe.d

rsandhu <at> graphite ~ $ getfilecon /run/{credentials,initramfs,modprobe.d}
/run/credentials        system_u:object_r:tmpfs_t:s0
/run/initramfs  system_u:object_r:tmpfs_t:s0
/run/modprobe.d system_u:object_r:tmpfs_t:s0

Since 432ad8738387f1b2e80e883dc7080df3afabe, coreutils attempts to list
all attributes instead of specifically getting the "security.selinux"
xattr via `getxattr(2)` (which is what libselinux internally calls). As
seen below, the security context xattr only shows when specifically
requesting it by passing the arguments -n 'security.selinux' to the
command line:
rsandhu <at> graphite ~ $ getfattr -d -m '' /run/credentials
<no output>
rsandhu <at> graphite ~ $ getfattr -n 'security.selinux' /run/credentials
getfattr: Removing leading '/' from absolute path names
# file: run/credentials
security.selinux="system_u:object_r:tmpfs_t:s0"

Reverting this commit[1], which no longer handles this case, fixes the
regression.
case.
More information is available in the related post on the SELinux mailing
list[2].

Thanks,
Rahul

[1] https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=4ce432ad8738387f1b2e80e883dc7080df3afabe
[2] https://lore.kernel.org/selinux/CAFqZXNtF8wDyQajPCdGn=iOawX4y77ph0EcfcqcUUj+T87FKyA <at> mail.gmail.com/

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Rahul Sandhu <nvraxn <at> gmail.com>, 77597 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Mon, 7 Apr 2025 19:03:08 +0100

On 06/04/2025 02:49, Rahul Sandhu wrote:
> Hey,
> 
> coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware
> builds. `ls -Z` fails to obtain the security context for certain
> filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with
> refpolicy:
> 
> rsandhu <at> graphite ~ $ ls -alZ /run/ | grep '?'
> drwxr-xr-x   3 root     root     ?                                               60 Apr  5 16:38 credentials
> drwxr-xr-x   3 root     root     ?                                               80 Apr  2 16:30 initramfs
> drwxr-xr-x   2 root     root     ?                                               40 Apr  2 16:23 modprobe.d

This may be fixed with https://github.com/coreutils/coreutils/commit/cb2abbac7

Could you try the latest snapshot to see if it fixes this for you?

  wget https://pixelbeat.org/cu/coreutils-ss.tar.xz
  tar -xf coreutils-ss.tar.xz
  cd coreutils-9.6.53-14af8/
  ./configure && make -j4
  src/ls -alZ /run/

thanks,
Pádraig.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Rahul Sandhu <nvraxn <at> gmail.com>, 77597 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Mon, 7 Apr 2025 19:22:43 +0100

On 07/04/2025 19:03, Pádraig Brady wrote:
> On 06/04/2025 02:49, Rahul Sandhu wrote:
>> Hey,
>>
>> coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware
>> builds. `ls -Z` fails to obtain the security context for certain
>> filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with
>> refpolicy:
>>
>> rsandhu <at> graphite ~ $ ls -alZ /run/ | grep '?'
>> drwxr-xr-x   3 root     root     ?                                               60 Apr  5 16:38 credentials
>> drwxr-xr-x   3 root     root     ?                                               80 Apr  2 16:30 initramfs
>> drwxr-xr-x   2 root     root     ?                                               40 Apr  2 16:23 modprobe.d
> 
> This may be fixed with https://github.com/coreutils/coreutils/commit/cb2abbac7
> 
> Could you try the latest snapshot to see if it fixes this for you?
> 
>     wget https://pixelbeat.org/cu/coreutils-ss.tar.xz
>     tar -xf coreutils-ss.tar.xz
>     cd coreutils-9.6.53-14af8/
>     ./configure && make -j4
>     src/ls -alZ /run/
> 

Actually sorry the above will not address this.
I'll have a deeper look now.

thanks,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Rahul Sandhu <nvraxn <at> gmail.com>, 77597 <at> debbugs.gnu.org
Cc: eggert <at> cs.ucla.edu
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Mon, 7 Apr 2025 20:04:23 +0100

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

On 07/04/2025 19:22, Pádraig Brady wrote:
> On 07/04/2025 19:03, Pádraig Brady wrote:
>> On 06/04/2025 02:49, Rahul Sandhu wrote:
>>> Hey,
>>>
>>> coreutils 9.6 appears to have a regression in `ls(1)` for SELinux-aware
>>> builds. `ls -Z` fails to obtain the security context for certain
>>> filesystem objects (e.g. `/sys`). Example to reproduce on Gentoo with
>>> refpolicy:
>>>
>>> rsandhu <at> graphite ~ $ ls -alZ /run/ | grep '?'
>>> drwxr-xr-x   3 root     root     ?                                               60 Apr  5 16:38 credentials
>>> drwxr-xr-x   3 root     root     ?                                               80 Apr  2 16:30 initramfs
>>> drwxr-xr-x   2 root     root     ?                                               40 Apr  2 16:23 modprobe.d
>>
>> This may be fixed with https://github.com/coreutils/coreutils/commit/cb2abbac7
>>
>> Could you try the latest snapshot to see if it fixes this for you?
>>
>>      wget https://pixelbeat.org/cu/coreutils-ss.tar.xz
>>      tar -xf coreutils-ss.tar.xz
>>      cd coreutils-9.6.53-14af8/
>>      ./configure && make -j4
>>      src/ls -alZ /run/
>>
> 
> Actually sorry the above will not address this.
> I'll have a deeper look now.

The attached gnulib patch passes quick tests here.
I'll think some more about it and apply later.

thanks,
Pádraig

[gnulib-selinux-empty-listxattr.patch (text/x-patch, attachment)]

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Rahul Sandhu <nvraxn <at> gmail.com>
Cc: 77597 <at> debbugs.gnu.org
Subject: Re: coreutils 9.6: regression in handling security.selinux attribute
 for ls(1)
Date: Mon, 7 Apr 2025 15:10:24 -0700

On 4/5/25 18:49, Rahul Sandhu wrote:

> the security context xattr only shows when specifically
> requesting it by passing the arguments -n 'security.selinux' to the
> command line:
> rsandhu <at> graphite ~ $ getfattr -d -m '' /run/credentials
> <no output>
> rsandhu <at> graphite ~ $ getfattr -n 'security.selinux' /run/credentials
> getfattr: Removing leading '/' from absolute path names
> # file: run/credentials
> security.selinux="system_u:object_r:tmpfs_t:s0"

I don't observe the problem on my Fedora 41 platform. What happens when 
you run this command?

strace -o tr getfattr -d -m '' /run/credentials

On Fedora, 'tr' ends like this:

...
newfstatat(AT_FDCWD, "/run/credentials", {st_mode=S_IFDIR|0755, 
st_size=200, ...}, AT_SYMLINK_NOFOLLOW) = 0
listxattr("/run/credentials", NULL, 0)  = 17
listxattr("/run/credentials", "security.selinux\0", 256) = 17
getxattr("/run/credentials", "security.selinux", NULL, 0) = 31
getxattr("/run/credentials", "security.selinux", 
"system_u:object_r:var_run_t:s0", 256) = 31
write(2, "getfattr: Removing leading '/' f"..., 56) = 56
...

which means listxattr is operating correctly. What does listxattr do on 
your platform?

If listxattr is returning 0, that would seem to be a bug in listxattr, 
and perhaps we can figure out which platforms have the bug and work 
around it. For example, perhaps we could run 'listxattr("/run", NULL, 
0)' and use a (slower) workaround only if that returns 0. The idea is to 
do the workaround only on the affected platforms.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Rahul Sandhu <nvraxn <at> gmail.com>, 77597 <at> debbugs.gnu.org
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Mon, 7 Apr 2025 15:10:31 -0700

On 4/7/25 12:04, Pádraig Brady wrote:
> The attached gnulib patch passes quick tests here.

This causes 'ls' to issue more syscalls per file, right? It'd be better 
if we could figure out a workaround just for the affected platforms, as 
opposed to slowing down 'ls' for everybody.

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>, Rahul Sandhu <nvraxn <at> gmail.com>
Cc: 77597 <at> debbugs.gnu.org
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Mon, 7 Apr 2025 23:52:17 +0100

On 07/04/2025 23:10, Paul Eggert wrote:
> On 4/5/25 18:49, Rahul Sandhu wrote:
> 
>> the security context xattr only shows when specifically
>> requesting it by passing the arguments -n 'security.selinux' to the
>> command line:
>> rsandhu <at> graphite ~ $ getfattr -d -m '' /run/credentials
>> <no output>
>> rsandhu <at> graphite ~ $ getfattr -n 'security.selinux' /run/credentials
>> getfattr: Removing leading '/' from absolute path names
>> # file: run/credentials
>> security.selinux="system_u:object_r:tmpfs_t:s0"
> 
> I don't observe the problem on my Fedora 41 platform. What happens when
> you run this command?
> 
> strace -o tr getfattr -d -m '' /run/credentials
> 
> On Fedora, 'tr' ends like this:
> 
> ...
> newfstatat(AT_FDCWD, "/run/credentials", {st_mode=S_IFDIR|0755,
> st_size=200, ...}, AT_SYMLINK_NOFOLLOW) = 0
> listxattr("/run/credentials", NULL, 0)  = 17
> listxattr("/run/credentials", "security.selinux\0", 256) = 17
> getxattr("/run/credentials", "security.selinux", NULL, 0) = 31
> getxattr("/run/credentials", "security.selinux",
> "system_u:object_r:var_run_t:s0", 256) = 31
> write(2, "getfattr: Removing leading '/' f"..., 56) = 56
> ...
> 
> which means listxattr is operating correctly. What does listxattr do on
> your platform?

I get the same for /run/credentials on Fedora 41 (6.13.6-200.fc41.x86_64) here,
but I do repro the issue with /run/initramfs.

  $ strace --trace=/.*xattr.* getfattr -d -m '' /run/initramfs
  listxattr("/run/initramfs", NULL, 0)    = 0

  $ strace --trace=/.*xattr.* getfattr -n 'security.selinux' /run/initramfs
  getxattr("/run/initramfs", "security.selinux", NULL, 0) = 29
  getxattr("/run/initramfs", "security.selinux", "system_u:object_r:tmpfs_t:s0", 256) = 29
  getfattr: Removing leading '/' from absolute path names
  # file: run/initramfs
  security.selinux="system_u:object_r:tmpfs_t:s0"


> If listxattr is returning 0, that would seem to be a bug in listxattr,
> and perhaps we can figure out which platforms have the bug and work
> around it. For example, perhaps we could run 'listxattr("/run", NULL,
> 0)' and use a (slower) workaround only if that returns 0. The idea is to
> do the workaround only on the affected platforms.

Unfortunately that won't work.

  $ strace --trace=/.*xattr.* getfattr -d -m '' /run/
  listxattr("/run/", NULL, 0)             = 17

I'm not sure how we could distinguish this case.

  $ stat /run/initramfs
    File: /run/initramfs
  Size: 60        	Blocks: 0          IO Block: 4096   directory
  Device: 0,26	Inode: 20          Links: 3
  Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
  Context: system_u:object_r:tmpfs_t:s0

  $ stat /run
    File: /run
    Size: 1600      	Blocks: 0          IO Block: 4096   directory
  Device: 0,26	Inode: 1           Links: 58
  Access: (0755/drwxr-xr-x)  Uid: (    0/    root)   Gid: (    0/    root)
  Context: system_u:object_r:var_run_t:s0

Note /run/initramfs is the only problematic entry for me,
and that's the only entry with "tmpfs_t" in the context.

As for efficiency, on SELinux systems listxattr() would generally never return 0,
but yes on others we'd we doing an extra getxattr().
So maybe we class this as a kernel bug and have the kernel
return non 0 for this case, or even ENOTSUP.

cheers,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 77597 <at> debbugs.gnu.org, Rahul Sandhu <nvraxn <at> gmail.com>
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Tue, 8 Apr 2025 00:06:44 -0700

On 2025-04-07 15:52, Pádraig Brady wrote:
> So maybe we class this as a kernel bug and have the kernel
> return non 0 for this case, or even ENOTSUP.

Yes, this sounds right to me. The kernel should not pretend that there 
are no attributes when there are attributes. If the kernel doesn't want 
to tell us attribute names, it should return -1 and set errno to a value 
saying "I don't want to tell you".

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 77597 <at> debbugs.gnu.org, Rahul Sandhu <nvraxn <at> gmail.com>
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Tue, 8 Apr 2025 08:37:28 +0100

On 08/04/2025 08:06, Paul Eggert wrote:
> On 2025-04-07 15:52, Pádraig Brady wrote:
>> So maybe we class this as a kernel bug and have the kernel
>> return non 0 for this case, or even ENOTSUP.
> 
> Yes, this sounds right to me. The kernel should not pretend that there
> are no attributes when there are attributes. If the kernel doesn't want
> to tell us attribute names, it should return -1 and set errno to a value
> saying "I don't want to tell you".

I suppose we could add another flag set with -Z,
with which we would enable the "double check" if 0 logic.
-Z is not a usual option, so trying harder in this case should be OK.

cheers,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 77597 <at> debbugs.gnu.org, Rahul Sandhu <nvraxn <at> gmail.com>
Subject: Re: bug#77597: coreutils 9.6: regression in handling security.selinux
 attribute for ls(1)
Date: Tue, 8 Apr 2025 13:27:58 +0100

On 08/04/2025 08:06, Paul Eggert wrote:
> On 2025-04-07 15:52, Pádraig Brady wrote:
>> So maybe we class this as a kernel bug and have the kernel
>> return non 0 for this case, or even ENOTSUP.
> 
> Yes, this sounds right to me. The kernel should not pretend that there
> are no attributes when there are attributes. If the kernel doesn't want
> to tell us attribute names, it should return -1 and set errno to a value
> saying "I don't want to tell you".

OK, given this is is an uncommon edge case
let's push for a kernel fix, rather than
a partial or inefficient workaround in ls.

Rahul can you report this to the appropriate kernel folks?

thank you,
Pádraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linux Kernel Mailing List <linux-kernel <at> vger.kernel.org>,
 linux-security-module <at> vger.kernel.org
Cc: 77597 <at> debbugs.gnu.org, Paul Eggert <eggert <at> CS.UCLA.EDU>,
 Rahul Sandhu <nvraxn <at> gmail.com>
Subject: listxattr() should return ENOTSUP for sysfs / tmpfs entries, not 0
Date: Wed, 23 Apr 2025 13:22:54 +0100

Older coreutils was less efficient and always called getxattr("security.selinux"),
and thus shows the SELinux context as expected:

  $ coreutils-9.3/src/ls -lZd /run/initramfs
  drwxr-xr-x. 3 root root system_u:object_r:tmpfs_t:s0 60 Apr 19 14:52 /run/initramfs
  $ coreutils-9.3/src/ls -lZd /sys/block
  drwxr-xr-x. 2 root root system_u:object_r:sysfs_t:s0 0 Apr 23 12:54 /sys/block

However newer coreutils is more efficient, and does not call getxattr()
if listxattr() returns 0 indicating that there are no xattrs.

  $ coreutils-9.7/src/ls -lZd /run/initramfs
  drwxr-xr-x 3 root root ? 60 Apr 19 14:52 /run/initramfs
  $ coreutils-9.7/src/ls -lZd /sys/block
  drwxr-xr-x 2 root root ? 0 Apr 23 12:54 /sys/block

I also noticed the same issue with the exa utility for example.
For coreutils to maintain efficient processing and to fix the issue centrally,
it would be more correct for listxattr() to return ENOTSUP,
in which case ls will try the getxattr() call and operate as expected.
Otherwise I can't see a way for coreutils to be both efficient and always correct.

I'm currently testing on kernel 6.14.2-300.fc42.x86_64

thanks,
Padraig

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

From: Pádraig Brady <P <at> draigBrady.com>
To: Linux Kernel Mailing List <linux-kernel <at> vger.kernel.org>,
 linux-security-module <at> vger.kernel.org
Cc: 77597 <at> debbugs.gnu.org, Paul Eggert <eggert <at> CS.UCLA.EDU>,
 Rahul Sandhu <nvraxn <at> gmail.com>
Subject: Re: bug#77597: listxattr() should return ENOTSUP for sysfs / tmpfs
 entries, not 0
Date: Fri, 23 May 2025 12:38:32 +0100

On 23/04/2025 13:22, Pádraig Brady wrote:
> Older coreutils was less efficient and always called getxattr("security.selinux"),
> and thus shows the SELinux context as expected:
> 
>     $ coreutils-9.3/src/ls -lZd /run/initramfs
>     drwxr-xr-x. 3 root root system_u:object_r:tmpfs_t:s0 60 Apr 19 14:52 /run/initramfs
>     $ coreutils-9.3/src/ls -lZd /sys/block
>     drwxr-xr-x. 2 root root system_u:object_r:sysfs_t:s0 0 Apr 23 12:54 /sys/block
> 
> However newer coreutils is more efficient, and does not call getxattr()
> if listxattr() returns 0 indicating that there are no xattrs.
> 
>     $ coreutils-9.7/src/ls -lZd /run/initramfs
>     drwxr-xr-x 3 root root ? 60 Apr 19 14:52 /run/initramfs
>     $ coreutils-9.7/src/ls -lZd /sys/block
>     drwxr-xr-x 2 root root ? 0 Apr 23 12:54 /sys/block
> 
> I also noticed the same issue with the exa utility for example.
> For coreutils to maintain efficient processing and to fix the issue centrally,
> it would be more correct for listxattr() to return ENOTSUP,
> in which case ls will try the getxattr() call and operate as expected.
> Otherwise I can't see a way for coreutils to be both efficient and always correct.
> 
> I'm currently testing on kernel 6.14.2-300.fc42.x86_64

FYI this should be addressed with:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b0ba61d

cheers,
Pádraig

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>,
 Linux Kernel Mailing List <linux-kernel <at> vger.kernel.org>,
 linux-security-module <at> vger.kernel.org,
 Stephen Smalley <stephen.smalley.work <at> gmail.com>
Cc: 77597 <at> debbugs.gnu.org, Rahul Sandhu <nvraxn <at> gmail.com>
Subject: Re: bug#77597: listxattr() should return ENOTSUP for sysfs / tmpfs
 entries, not 0
Date: Sat, 31 May 2025 08:25:07 -0700

On 2025-05-23 04:38, Pádraig Brady wrote:
> FYI this should be addressed with:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8b0ba61d

Thanks for letting me know, as this led me to further testing that found 
some other kernel bugs in this area, possibly introduced by that kernel 
commit. Please see:

"flistxattr with right size wrongly fails with ERANGE, breaking 'cp -a' 
etc" <https://bugzilla.redhat.com/show_bug.cgi?id=2369561>

The email thread starting at "[PATCH] Fix listxattr-related races and 
stack overflows" 
<https://lists.nongnu.org/archive/html/acl-devel/2025-05/msg00003.html>.

Previous Next

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