Hi Tejun,
On Fri, Aug 16, 2013 at 11:47:57AM -0400, Tejun Heo wrote:
> On Fri, Aug 16, 2013 at 11:20:26AM -0400, Aristeu Rozanski wrote:
> > > e.g. if a cgroup will be allowed to be moved to another position in
> > > the hierarchy, the cgroup shouldn't change its configuration across
> > > such migration, right? If so, we'd be allowing creating a cgroup
> > > outside the hierarchy with any configuration moving it under another
> > > while disallowing creating it under there and creating the same
> > > configuration, which would be an outright buggy behavior.
> >
> > Hm, then I think I got the requirements wrong. On my understanding you
> > cannot have a cgroup with more access than its parent. And the reason
> > for that is at that time the idea of having a container able to control
> > its own hierarchy was valid.
>
> Oh yes, sure, a descendant shouldn't have access to devices which
> aren't allowed by its ancestors but that doesn't mean it can't have a
> rule to allow such access. It just wouldn't make any difference at
> that point. If the ancestors later change the configuration such that
> the device is allowed, the cgroup will have access to that
> automatically. Rules configured and rules being applied need to be
> distinguished and the latter doesn't need to affect the former.
>
> > The way it is right now, when moved, a cgroup would have its active
> > rules re-checked for permission and it'd be made an attempt to apply
> > local rules if the new parent allows it.
>
> 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.
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?
--
Aristeu
--
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
