Hello,
On Fri, Aug 16, 2013 at 12:02:04PM -0400, Aristeu Rozanski wrote:
> > Yeah, that's the correct behavior, if I'm not misunderstanding you,
> > but to be consistent we also need to allow creating rules which allow
> > devices which aren't allowed by ancestors. It won't be applicable at
> > rule creation but may later become effective later on.
>
> Oh, I see, it's just matter of allowing to set the desired set or rules
> locally even if they're not possible at the moment.
Yeah, otherwise, we'd get into situation where setting rules in place
isn't allowed but moving it out of hierarchy, setting it and then
moving it back would work, which doesn't make much sense.
> So, considering we drop in sane_behavior the allow + exceptions case,
> the interface in sane_behavior mode would look like:
> - policy: {allow_all,deny}
> writing either will clear the active aw
> - active_whitelist
> list of in effect rules, read only
> - whitelist
> list of locally set rules, read only
> - whitelist_add
> write only, adds rule to the local list and active lists
> - whitelist_remove
> write only, removes rule from the local and active lists
>
> What you think?
Yeah, I think that should work although you might also need
active_policy and "effective" might be a better choice as prefix.
Kay, Lennart, what do you guys think?
Thanks.
--
tejun
--
To unsubscribe from this list: send the line "unsubscribe cgroups" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
