Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

[W. Trevor King]

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