Re: "ls -l": Avoid unnecessary getxattr() overhead

[Pádraig Brady]

On 02/19/2012 10:22 PM, Sven Breuner wrote:
> Jim Meyering wrote on 02/19/2012 06:00 PM:
>> Pádraig Brady wrote:
>>> > From Sven's strace it seems that lgetfilecon() is interpreting
>>> the "unlabeled" return from lgetxattr() and converting that
>>> into a -1 return with ENODATA?  That's the only logical explanation
>>> I can see for how ENODATA is significant. As mentioned before
>>> I'm not sure we could add ENODATA to errno_unsupported().
>>
>> Right.  We definitely don't want to add ENODATA.
>> I removed it for this sort of reason.
>>
>> The gnulib getfilecon wrapper maps 10,"unlabeled" to -1,ENODATA.
> 
> Is there maybe another check that could be used to find out if selinux is 
> disabled? (e.g. is_selinux_enabled(3) )

I'm not sure you could use that.
Even though it's currently disabled,
you might be surprised that ls didn't
indicate selinux attributes as normal.

> 
>> Back when I wrote that wrapper, it sounded like 10,"unlabeled"
>> would happen only with kernels deemed crufty back then (in 2009).
>>
>>    http://thread.gmane.org/gmane.comp.gnu.coreutils.bugs/18378/focus=18384
>>
>> That we're still seeing such syscall traces in 2012...
> 
> I guess that means it's more or less intended that userspace does get ENODATA 
> or "unlabled" instead of EOPNOTSUPP - to show that the system uses a kernel 
> which is generally selinux compatible, even though selinux is disabled.

In the referenced thread above, there is a 2006 kernel patch
which seems to remove this "unlabeled" thing.
Though that doesn't seem to correlate with your testing against 
~/tmp/ls_20120209.

I just booted RHEL 6.2 with selinux=0 on the kernel command line,
so as I could test new files without a context created, and...

getxattr("security.selinux") on existing files on ext4, returns the existing 
attribute
getxattr("security.selinux") on new files on ext4, returns ENODATA
getxattr("security.selinux") on new files on tmpfs, returns ENOTSUP

So is this "unlabeled" coming from some really old kernel?
I thought you were on RHEL 6.2? Actually I went back to your
original report (I presume also on RHEL 6.2) and saw:

lgetxattr("test", "security.selinux", 0x62d130, 255) = -1 ENODATA (No data 
available)

I.E. "unlabeled" was not returned there either.
What's changed?

In any case "unlabeled" is mapped to ENODATA which is correct I think,
and ENODATA can't be taken as device wide as stated before.

> On the other hand, all the scientific compute clusters I know have selinux 
> permanently disabled, because they just don't want to have anything to do 
> with it. Since these are typically the guys with the large directories, I 
> would say it's not right to let them wait longer for their "ls -l" result, 
> just because their kernel is generally selinux compatible.
> 
> So would skipping these calls for "ls -l" be an option on a system with 
> disabled selinux? I assume the people who want to check their selinux labels 
> could use "ls -Z" or have other tools available to check this information. 
> And those people probably wouldn't set selinux disabled, but rather use 
> permissive mode instead.

So the options we have now are:

1. If the file system really doesn't support selinux attributes, it should 
return ENOTSUP,
like tmpfs does above. That will trigger the cache in the existing code.

2. We may in future support a --format option in ls, to give greater
control over what is output (and thus queried).

cheers,
Pádraig.