On Mon, Oct 14, 2013 at 5:11 PM, Kok, Auke-jan H <[email protected]>wrote:
> On Mon, Oct 14, 2013 at 4:21 PM, Michael Demeter > <[email protected]> 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
_______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
