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

[Sven Breuner]

Pádraig Brady wrote on 02/20/2012 12:54 AM:
> On 02/19/2012 10:22 PM, Sven Breuner wrote:
> > 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.

Agreed, changing behavior that someone might be relying on wouldn't be 
good. So I would say the question is whether someone with disabled 
selinux would really rely on ls reporting selinux attributes in the "ls 
-l" output.


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

The way I understood it, that patch should just avoid storing those 
attributes on disk. It wasn't intended to completely remove the 
existence of "unlabled".

$ git show 8aad38752e81d1d4de67e3d8e2524618ce7c9276
[...]
SELinux always maintains a safe internal label if there is none, so with 
this patch, we just stick with that and wait until a policy is loaded 
before adding a persistent label on disk.
[...]


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

Seems to be inconsistent. Some of our RHEL 6.x systems return "unlabled" 
on a tmpfs:

a) RHEL 6.1...
$ uname -r
2.6.32-131.21.1.el6.x86_64
$ sestatus
SELinux status:                 disabled
$ mount -t tmpfs none /mnt/tmp
$ touch /mnt/tmp/file
$ strace ls -l /mnt/tmp/file 2>&1 | grep security
lgetxattr("/mnt/tmp/file", "security.selinux", "unlabeled", 255) = 10

b) Same "unlabeled" result for another machine with RHEL 6.2 kernel 
2.6.32-220.4.1.el6.x86_64.

c) But then the third machine with RHEL kernel 2.6.32-220.2.1.el6.x86_64 
shows EOPNOTSUPP in the same tmpfs test case:
$ strace ls -l /mnt/tmp/file 2>&1 | grep security
lgetxattr("/mnt/tmp/file", "security.selinux", 0x623300, 255) = -1 
EOPNOTSUPP (Operation not supported)

All of these systems are fresh RHEL 6 installs, which never ran on an 
old kernel and never had selinux enabled (though that probably shouldn't 
make a difference on a tmpfs).

The fhgfs result in these cases is similar to the tmpfs result: 
"unlabled" on machines a/b and EOPNOTSUPP on machine c.

Strange. The only thing I can conclude from these results is that there 
is a difference in the selinux configuration of these machines that is 
effective even though selinux is disabled. (Just don't know where to 
look for that difference to verify this assumption.)

If we assume that there is something wrong with machines a/b and all 
those systems actually should be returning EOPNOTSUPP in a "normal" 
setup, then the current cache implementation would work perfectly fine, 
of course.

Best regards,
Sven