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

[James Bottomley]

On Thu, 2016-07-21 at 09:33 -0500, Serge E. Hallyn wrote:
> Quoting Aleksa Sarai (asarai@xxxxxxx):

> > > > The reason I'm doing this is so that we might be able to
> > > > _practically_ use cgroups as an unprivileged user (something
> > > > that will almost certainly be useful to not just the container
> > > > crowd, but people also planning on using cgroups as advanced
> > > > forms of rlimits).
> > > 
> > > I don't get why we need this fragile dance with permissions at 
> > > all when the same functionality can be achieved by delegating
> > > explicitly.
> > 
> > The key words being "unprivileged user". Currently, if I am a
> > regular user on a system and I want to use the freezer cgroup to
> > pause a process I am running, I have to *go to the administrator 
> > and ask them to give me permission to do that*. Why is that
> > necessary?
> 
> Ths is of course solvable using something like libpam-cgfs or
> libpam-cgm (and others).  Since this sounds like a question of
> policy, not mechanism, userspace seems like the right place.  Is
> there a downside to that (or, as Tejun put it, "delegating 
> explicitly")?

Unprivileged containers should "just work" by default as much as
possible.  There are cases where they can't and policy input is
required, like the userns mapping to additional ids beyond the current
one, we can still set up the default case without intervention (a
single mapping root to current id).

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).

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?

James