I'm just chipping in from the peanut gallery, so sorry if this misses some earlier discussion. On Fri, May 20, 2016 at 12:53:26PM -0400, Tejun Heo wrote: > Why does an unpriv NS need to have cgroup delegated to it without > cooperation from cgroup manager? If for resource control, I'm > pretty sure we don't want to allow that without explicit cooperation > from the enclosing scope. A useful analogy is renice(1), which allows users to manage the way their allocated resources are distributed among their processes. A system where a sysadmin has to explicitly grant users permission to use renice seems overly restrictive, as does a system where a sysadmin has to explicitly grant users permission to use cgroups to manage their resources. At that level, the only different is probably that adjusting niceness doesn't consume additional system resources, while creating a new cgroup does, and sysadmins might want to protect themselves from having users create zillions of cgroups. On the other hand, sysadmins who do want to grant this power can automatically put users in their own cgroup with adjusted POSIX permissions at login time (e.g. “Hi Alice, here's your own cgroup to manage as you see fit. Hi Bob, …”). But having a way to say “I'm fine with users creating their own cgroup namespaces and sub-cgroups” is easier. And making it opt-out (“I'm *not* fine with users creating their own…”) is even easier, and the choice between opt-in and opt-out probably depends on how expensive cgroups are. Cheers, Trevor -- This email may be signed or encrypted with GnuPG (http://www.gnupg.org). For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
Attachment:
signature.asc
Description: OpenPGP digital signature
