Re: selinux vs devtmpfs (vs udev)

[Harald Hoyer]

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?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/