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