From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754819AbcETQEI (ORCPT ); Fri, 20 May 2016 12:04:08 -0400 Received: from mail-io0-f175.google.com ([209.85.223.175]:33455 "EHLO mail-io0-f175.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751883AbcETQEF (ORCPT ); Fri, 20 May 2016 12:04:05 -0400 Date: Fri, 20 May 2016 09:03:52 -0700 From: Tejun Heo To: James Bottomley Cc: Aleksa Sarai , Li Zefan , Johannes Weiner , Aleksa Sarai , cgroups@vger.kernel.org, linux-kernel@vger.kernel.org, dev@opencontainers.org Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces Message-ID: <20160520160352.GC5632@htj.duckdns.org> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1463758258.8091.3.camel@HansenPartnership.com> User-Agent: Mutt/1.6.1 (2016-04-27) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, James. On Fri, May 20, 2016 at 11:30:58AM -0400, James Bottomley wrote: > Given it's merge window time, I haven't yet had time to look at the > patch, but I can tell you why it (or something like it) is necessary: > unprivileged containers need to be able to set up cgroups as well as > namespaces, so we do need a way for the user ns owner to modify cgroups > in their default configuration otherwise cgroups just won't fit into > the unprivileged model. Whether this should be through the cgroup ns That can be allowed by delegating a cgroup sub-hierarchy to the unpriviledged user. Sub-cgroups created by that user will be owned by that user. IOW, if the owner of the cgroup hierarchy doesn't explicitly delegate the subtree, the unpriv user can't have the subtree. This is true for regular use cases and shouldn't be different for namespaces. > is up for debate, as is how we should actually allow this to happen and > what we should present to the user ns owner, but we do need a way to do > this. > > Delegation can't be through chmodding in this case because the user ns > owner can't chmod something owned by init_user_ns root. I still don't see why the existing mechanisms (including userns if delegation from inside a ns is necessary) aren't enough. And even if we need something, I'd much prefer not to add a behavior which wildly deviates from the usual rules. Thanks. -- tejun