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
