From mboxrd@z Thu Jan 1 00:00:00 1970 From: Aleksa Sarai Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces Date: Sat, 21 May 2016 02:29:55 +1000 Message-ID: <573F3B83.3020206@suse.de> References: <1463196000-13900-1-git-send-email-asarai@suse.de> <573F23D0.2030500@suse.de> <20160520152244.GB5632@htj.duckdns.org> <1463758258.8091.3.camel@HansenPartnership.com> <20160520160352.GC5632@htj.duckdns.org> <1463760550.8091.13.camel@HansenPartnership.com> <20160520161759.GD5632@htj.duckdns.org> <1463761509.8091.19.camel@HansenPartnership.com> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <1463761509.8091.19.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org> Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: James Bottomley , Tejun Heo Cc: Li Zefan , Johannes Weiner , Aleksa Sarai , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, dev-IGmTWi+3HBZvNhPySn5qfx2eb7JE58TQ@public.gmane.org >> This is stemming from the fact that an unpriv application can't >> create its sub-cgroups without explicit delegation from the root and >> that has always been an explicit design choice. >> It's tied to who's responsible for cleanup afterwards and what >> happens when the process gets migrated to a different cgroup. The >> latter is an important issue on v1 hierarchies because migrating >> tasks sometimes is used as a way to control resource distribution. > > OK, so is the only problem cleanup? If so, what if I proposed that a > cgroup directory could only be created by the owner of the userns > (which would be any old unprivileged user) iff they create a cgroup ns > and the cgroup ns would be responsible for removing it again, so the > cgroup subdirectory would be tied to the cgroup namespace as its holder > and we'd use release of the cgroup to remove all the directories? The only question I'd have is how would we deal with visibility (and should a "parent" cgroup namespace be able to modify things inside the cgroup?). And of course, how would that interact with VFS? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/ From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755952AbcETQaI (ORCPT ); Fri, 20 May 2016 12:30:08 -0400 Received: from mx2.suse.de ([195.135.220.15]:59648 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754840AbcETQaG (ORCPT ); Fri, 20 May 2016 12:30:06 -0400 Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces To: James Bottomley , Tejun Heo References: <1463196000-13900-1-git-send-email-asarai@suse.de> <573F23D0.2030500@suse.de> <20160520152244.GB5632@htj.duckdns.org> <1463758258.8091.3.camel@HansenPartnership.com> <20160520160352.GC5632@htj.duckdns.org> <1463760550.8091.13.camel@HansenPartnership.com> <20160520161759.GD5632@htj.duckdns.org> <1463761509.8091.19.camel@HansenPartnership.com> Cc: Li Zefan , Johannes Weiner , Aleksa Sarai , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, dev@opencontainers.org From: Aleksa Sarai Message-ID: <573F3B83.3020206@suse.de> Date: Sat, 21 May 2016 02:29:55 +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: <1463761509.8091.19.camel@HansenPartnership.com> Content-Type: text/plain; charset=utf-8; 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 stemming from the fact that an unpriv application can't >> create its sub-cgroups without explicit delegation from the root and >> that has always been an explicit design choice. >> It's tied to who's responsible for cleanup afterwards and what >> happens when the process gets migrated to a different cgroup. The >> latter is an important issue on v1 hierarchies because migrating >> tasks sometimes is used as a way to control resource distribution. > > OK, so is the only problem cleanup? If so, what if I proposed that a > cgroup directory could only be created by the owner of the userns > (which would be any old unprivileged user) iff they create a cgroup ns > and the cgroup ns would be responsible for removing it again, so the > cgroup subdirectory would be tied to the cgroup namespace as its holder > and we'd use release of the cgroup to remove all the directories? The only question I'd have is how would we deal with visibility (and should a "parent" cgroup namespace be able to modify things inside the cgroup?). And of course, how would that interact with VFS? -- Aleksa Sarai Software Engineer (Containers) SUSE Linux GmbH https://www.cyphar.com/