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

[Pádraig Brady]

On 02/20/2012 02:06 AM, Sven Breuner wrote:
> 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.

Yep. That's what I'm thinking is appropriate for fhgfs.
My kernel is 2.6.32-221 BTW.

I thought the difference might be selinux=0 boot param,
versus selinux=disabled in /etc/selinux/config, but that's not significant.

I notice that mount options can give a default context.
Is that being used in your "unlabeled" cases?
I.E. are there any *context options present?

If you can't spot the difference, then this is a good question
for an selinux mailing list I think.

cheers,
Pádraig.