Why does devices cgroup check for CAP_SYS_ADMIN explicitly?

[Aristeu Rozanski]

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