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

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@graphite ~ $ getfattr -d -m '' /run/credentials
> <no output>
> rsandhu@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.