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

[Aleksa Sarai <asarai@suse.de>]

This is an updated (and rewritten) version of v3 of this patchset[1].

The main difference is that I changed how we the "allow management" is
implemented. Rather than just chmod-ing the cgroup directory (which
everyone agreed was quite an odd way of doing it),
unshare(CLONE_NEWCGROUP) will create a new subtree in every cgroup the
task is associated with. The task will then be migrated to those
subtrees (which form the root cset of the cgroup namespace). This change
will be transparent to namespaced processes, and they'll gain a new
ability (the ability to create cgroups).

The name of the cgroup is randomly generated to ensure we don't get
conflicts (but maybe this should be dealt with in a nicer way). In
addition, I've updated the cgroup.procs write permission checks to be
user namespace aware, but I also added an additional "permitted" case
(where all of the tasks are in the same cgroup namespace and %current
has CAP_SYS_ADMIN in all of the relevant user namespaces).

I'm not _completely_ convinced about the addition of that case, and
maybe we should drop it (but I might be biased since this all comes from
the requirements of rootless containers).

Also, I haven't added a way to disable the functionality on a per-cgroup
(or even global) basis. Maybe there should be a way to do that, but I'm
not sure how it should be done (a cgroup.ns_subtrees file that allows
administrators to change it on a per-cgroup basis, or just a sysctl?).

PTAL.

[1]: https://lkml.org/lkml/2016/5/2/280

Aleksa Sarai (2):
  cgroup: make cgroup.procs permissions userns-aware
  cgroup: implement subtree creation on copy_cgroup_ns()

 kernel/cgroup.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++---------
 1 file changed, 126 insertions(+), 23 deletions(-)

-- 
2.8.2