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

[Sven Breuner]

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

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

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.

Best regards,
Sven