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