-----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@xxxxxxxxxx> 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? > Why is the kernel creating the devices versus telling udev to create the devices? You could write a hack that says don't relabel devices with MLS != s0. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAkx9GDYACgkQrlYvE4MpobMBBACfen8P0i1LJjufe2Gzdi2mn+tM OdwAn1nHM1M34MGahwS7tNlLLpfmadcC =hBOX -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.