[systemd-devel] [PATCH] Smack enabled systems need /dev special devices correctly labeled

[Demeter, Michael]

On Mon, Oct 14, 2013 at 5:11 PM, Kok, Auke-jan H
<auke-jan.h.kok at intel.com>wrote:

> On Mon, Oct 14, 2013 at 4:21 PM, Michael Demeter
> <michael.demeter at intel.com> wrote:
> >> That's not the point, the point is is if *belongs* into the systemd
> >> repo, not if it's *enabled* by default or not. From what I see, it's
> >> nothing really we should ship upstream.
> >
> > If Smack is enabled in systemd it starts very early and all of the
> special
> > devices need to be labeled properly for correct operation
>
> the question isn't whether this should be udev rules or not, since
> that's obvious - there is no other way to set these permissions than
> through udev rules.
>
> the discussion is whether these should ship with the upstream systemd
> project, or are vendor specific and should be maintained downstream.
>
> As I explained in my other e-mail, these rules (I'm not saying they
> are the right ones, I'm really not that much of a udev rule expert
> here!) are irregardless of any policy and are useful to anyone who
> enables Smack, so there's a strong preference, and benefit from having
> these rules here, and not in a downstream project.
>
> >> Also, it should not repeat the primary permissions settings from the
> >> default rules, that is just not right.
> >
> > This was done at Auke's request since the rule is adding the SECLABEL
> > for debugability to have the original rule present was desirable.
>
> That's just me not knowing udev well, so let's remove the permissions
> if they just duplicate things.
>
> Would it be preferable to replace the 50-udev-default rules completely
with a Smack enabled version during the build?

 This would then eliminate the duplication of rules.


> Auke
>



-- 
Michael Demeter
Sr. Software Engineer
Open Source Technology Center - SSG
Intel Corporation
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/systemd-devel/attachments/20131015/2927ed95/attachment.html>