From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753164AbcGUO7N (ORCPT ); Thu, 21 Jul 2016 10:59:13 -0400 Received: from mail-pf0-f194.google.com ([209.85.192.194]:34382 "EHLO mail-pf0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752813AbcGUO7J (ORCPT ); Thu, 21 Jul 2016 10:59:09 -0400 Date: Thu, 21 Jul 2016 10:59:05 -0400 From: Tejun Heo To: James Bottomley Cc: "Serge E. Hallyn" , Aleksa Sarai , Greg Kroah-Hartman , Li Zefan , Johannes Weiner , "Serge E. Hallyn" , Aditya Kali , Chris Wilson , linux-kernel@vger.kernel.org, cgroups@vger.kernel.org, Christian Brauner , dev@opencontainers.org Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Message-ID: <20160721145905.GC22680@htj.duckdns.org> References: <20160718161816.13040-1-asarai@suse.de> <20160718161816.13040-4-asarai@suse.de> <20160720155147.GG4574@htj.duckdns.org> <6e975d80-4077-fb8b-ec84-708e37c8e149@suse.de> <20160720230228.GA19588@mtj.duckdns.org> <982fcf3a-3685-9bd7-dd95-7bff255c9421@suse.de> <20160720231949.GB19588@mtj.duckdns.org> <379e5b13-29d4-ca75-1935-0a64f3db8d27@suse.de> <20160721143330.GA5751@mail.hallyn.com> <1469112709.2331.11.camel@HansenPartnership.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1469112709.2331.11.camel@HansenPartnership.com> User-Agent: Mutt/1.6.2 (2016-07-01) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hello, James. On Thu, Jul 21, 2016 at 07:51:49AM -0700, James Bottomley wrote: > What I haven't really heard yet in the debate is the policy reason why > an unprivileged user shouldn't set up their own cgroups as children of > the current ones (inheriting the constraints). It's not even about policies. The interface just can't support operations like this in a robust way. We can try to hack enough holes at it to make some scenarios work but it's all but guaranteed that such approach is gonna cause painful long-term issues. > I have heard > > * it would give power to move other tasks to more rigid constraints. >  To which the answer is only to allow movememnt of tasks in the > current cgroupns > * It violates the permissions delegation model.  This one doesn't > really make too much sense to me: in the same way the userns is root > in its own domain, cgroups ns is effective root for the restricted > cgroups (and only for processes within its ns). > > Perhaps the question should be asked the other way around: if we were > explicitly delegating permission to every user in the system to set up > their own sub cgroups, how would you advise it be done? Coordinate in userspace. Request whatever is managing the cgroup hierarchy to set up delegation. It's not like permission model is fully contained in kernel on modern systems anyway. Thanks. -- tejun