lkml.org 
[lkml]   [2010]   [Aug]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: selinux vs devtmpfs (vs udev)
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 08/31/2010 10:39 AM, Harald Hoyer wrote:
> On 08/31/2010 04:11 PM, Daniel J Walsh wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On 08/31/2010 04:44 AM, Harald Hoyer wrote:
>>> On 08/31/2010 01:14 AM, Eric Paris wrote:
>>>> On Sat, 2010-08-28 at 11:57 +0200, Kay Sievers wrote:
>>>>> On Sat, Aug 28, 2010 at 01:00, Eric Paris<eparis@redhat.com> wrote:
>>>>
>>>>>> In the new new days of devtmpfs things aren't as nice. The kernel is
>>>>>> magically creating files in /dev. These are getting created with the
>>>>>> 'default' SELinux context. So herein lies the problem.
>>>>>>
>>>>>> The first program that tries to access these files get denied by
>>>>>> SELinux. Now udev actually has logic in it to fix the label on any
>>>>>> closed device file, so udev will at that point swoop in, fix the
>>>>>> label,
>>>>>> and the next program that tries to use the file will work just
>>>>>> fine. Oh
>>>>>> fun!
>>>>
>>>>> Udev should still label all device nodes, even when they are created
>>>>> by the kernel. Devtmpfs or not should not make a difference here.
>>>>>
>>>>> I guess it's a udev bug introduced with:
>>>>>
>>>>> http://git.kernel.org/?p=linux/hotplug/udev.git;a=commitdiff;h=578cc8a8085a47c963b5940459e475ac5f07219c
>>>>>
>>>>>
>>>>>
>>>>> and we just need to fix that.
>>>>
>>>> Looks like the likely cause. I see a note in one of the bugzillas that
>>>> says:
>>>>
>>>> Aug 30 14:03:09 pippin udevd-work[347]: preserve file '/dev/dri/card0',
>>>> because it has correct dev_t
>>>>
>>>> Which is certainly the part of code in question. Do you have a quick
>>>> fix in mind that you plan to push upstream or should I ask the RH udev
>>>> guy to come up with something?
>>>>
>>>> -Eric
>>>>
>>>
>>> The RH udev guy says:
>>>
>>> This patch was introduced, because Red Hat engineers requested, that the
>>> selinux context should not be modified, after they set their own custom
>>> context (virtual machine management).
>>>
>>> So, either we differentiate between "add" and "change" events, or we
>>> should check against the "kernel default" selinux context, before we
>>> call udev_selinux_lsetfilecon().
>>>
>> So the problem is happening because the kernel creates the device rather
>> then udev, and then udev does not change the context because it can not
>> differentiate between this and libvirt putting down a label.
>
> Is there an easy test to differentiate?
>
Another option would be to check the label of the containing directory
and if they match run the lsetfilecon, If they don't then leave it be.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkx9GGgACgkQrlYvE4MpobNwkgCgvzHFWYTZND+xMSukZXc1M+a0
fC4AoNaVap4UfoOoq1U+8X7JWYqktNHy
=TljD
-----END PGP SIGNATURE-----


\
 
 \ /
  Last update: 2010-08-31 17:01    [W:0.077 / U:0.436 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site