Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

[Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>]

Hello, James.

On Thu, Jul 21, 2016 at 07:51:49AM -0700, James Bottomley wrote:
> What I haven't really heard yet in the debate is the policy reason why
> an unprivileged user shouldn't set up their own cgroups as children of
> the current ones (inheriting the constraints).

It's not even about policies.  The interface just can't support
operations like this in a robust way.  We can try to hack enough holes
at it to make some scenarios work but it's all but guaranteed that
such approach is gonna cause painful long-term issues.

> I have heard
> 
>  * it would give power to move other tasks to more rigid constraints. 
>     To which the answer is only to allow movememnt of tasks in the
>    current cgroupns
>  * It violates the permissions delegation model.  This one doesn't
>    really make too much sense to me: in the same way the userns is root
>    in its own domain, cgroups ns is effective root for the restricted
>    cgroups (and only for processes within its ns).
> 
> Perhaps the question should be asked the other way around:  if we were
> explicitly delegating permission to every user in the system to set up
> their own sub cgroups, how would you advise it be done?

Coordinate in userspace.  Request whatever is managing the cgroup
hierarchy to set up delegation.  It's not like permission model is
fully contained in kernel on modern systems anyway.

Thanks.

-- 
tejun