On Tue, Nov 06, 2012 at 07:41:05AM -0800, Tejun Heo wrote: > On Tue, Nov 06, 2012 at 09:30:32AM -0600, Serge Hallyn wrote: > > > So, you don't really have any actual use case for the explicit CAP_* > > > checks, right? > > > > No, especially since we will now have user namespaces. > > > > We will want to be able to strictly enforce hierarchical limits - i.e. > > allow uid 100000 (which is uid 0 in the container) to change cgroup > > settings, but never exceed limits set on the parent directory. IIUC > > you are working toward anyway with the general hierarchy work? (thanks > > for that). > > Yeah, I'm working toward that but I'm not sure it would mean that > containers would be able to directly bind mount cgroupfs subdirectory > and have free reign on it. Maybe such thing can be made to work but I > would be much more comfortable having something inbetween for > impedance matching (in access policies, root cgroup behavior matching, > whatnot). So, the functionality will be there but it probably would > need something inbetween if you wanna give containers control over its > own cgroup hierarchy. > > There are some issues tho. As it currently stands, devices cgroup > inherits configuration rather than enforcing hierarchy while checking > for access permission. This means that changes in an ancestor have to > be propagated downwards and *update* configurations of descendants, > which is what I'm working on but it can be confusing for someone > inside the container. Without breaking compatibility, I don't see any > other way out tho. I suppose it's something we'll have to live with. yes, but most of the changes will happen before the containers start. I've been working in a patchset (as promised) and it propagates down the changes and also keep 'local' rules. everytime a parent change something, the local rules are re-evaluated and reapplied if they're still valid. -- Aristeu _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
