From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755793AbcGTXTy (ORCPT ); Wed, 20 Jul 2016 19:19:54 -0400 Received: from mail-qt0-f195.google.com ([209.85.216.195]:33253 "EHLO mail-qt0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755699AbcGTXTv (ORCPT ); Wed, 20 Jul 2016 19:19:51 -0400 Date: Wed, 20 Jul 2016 19:19:49 -0400 From: Tejun Heo To: Aleksa Sarai Cc: 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, James Bottomley Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Message-ID: <20160720231949.GB19588@mtj.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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <982fcf3a-3685-9bd7-dd95-7bff255c9421@suse.de> 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, Aleksa. On Thu, Jul 21, 2016 at 09:18:59AM +1000, Aleksa Sarai wrote: > I feel like the permission model makes sense in certain cases (the common > ancestor restriction, as well as the ability for a parent to apply limits to > children by setting its own limits). Neither of those are violated (if you > read the commit that introduced the common ancestor restriction). > > Maybe if you give me a usecase of when it might be important that a process > must not be able to move to a sub-cgroup of its current one, I might be able > to understand your concerns? From my perspective, I think that's actually > quite useful. cgroup is used to keep track of which processes belong where and allowing processes to be moved out of its cgroup like this would be surprising to say the least. > > Maybe I'm misunderstanding but I can't see how that would change the > > situation in a significant way. > > Well, it would avoid the issue of a process being moved against *its* will. > The process would have to be complicit in joining (or unsharing) a cgroup > namespace. I'm not sure I really agree with the argument that a higher level > process should be able to stop a process from imposing more *stringent* > limits on itself if the process is complicit in setting those limits (see > above). > > The reason I'm doing this is so that we might be able to _practically_ use > cgroups as an unprivileged user (something that will almost certainly be > useful to not just the container crowd, but people also planning on using > cgroups as advanced forms of rlimits). I don't get why we need this fragile dance with permissions at all when the same functionality can be achieved by delegating explicitly. Thanks. -- tejun