Hello, Aristeu. 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. Thanks a lot for working on this! -- 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
