[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "ls -l": Avoid unnecessary getxattr() overhead
From: |
Pádraig Brady |
Subject: |
Re: "ls -l": Avoid unnecessary getxattr() overhead |
Date: |
Mon, 20 Feb 2012 10:54:55 +0000 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 |
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.
- Re: "ls -l": Avoid unnecessary getxattr() overhead, (continued)
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Sven Breuner, 2012/02/18
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Jim Meyering, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Pádraig Brady, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Jim Meyering, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Sven Breuner, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Pádraig Brady, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Sven Breuner, 2012/02/19
- Re: "ls -l": Avoid unnecessary getxattr() overhead,
Pádraig Brady <=
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Sven Breuner, 2012/02/20
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Sven Breuner, 2012/02/26
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Pádraig Brady, 2012/02/26
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Pádraig Brady, 2012/02/20
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Jim Meyering, 2012/02/20
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Eric Blake, 2012/02/17
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Jim Meyering, 2012/02/17
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Eric Blake, 2012/02/17
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Jim Meyering, 2012/02/17
- Re: "ls -l": Avoid unnecessary getxattr() overhead, Bernhard Voelker, 2012/02/17