From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755942AbcETOtH (ORCPT ); Fri, 20 May 2016 10:49:07 -0400 Received: from mx2.suse.de ([195.135.220.15]:45678 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751618AbcETOtE (ORCPT ); Fri, 20 May 2016 10:49:04 -0400 Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces To: Tejun Heo , Li Zefan , Johannes Weiner References: <1463196000-13900-1-git-send-email-asarai@suse.de> Cc: James Bottomley , Aleksa Sarai , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, dev@opencontainers.org From: Aleksa Sarai Message-ID: <573F23D0.2030500@suse.de> Date: Sat, 21 May 2016 00:48:48 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.2 MIME-Version: 1.0 In-Reply-To: <1463196000-13900-1-git-send-email-asarai@suse.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > 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(-) > Are there any comments on this version of the patchset? I thought we had reached an agreement that the underlying feature (allowing a process to manage its own cgroups) was useful. Is there a better way of solving this problem, that I don't know of? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/