From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932352AbcGTXCd (ORCPT ); Wed, 20 Jul 2016 19:02:33 -0400 Received: from mail-yw0-f195.google.com ([209.85.161.195]:33738 "EHLO mail-yw0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932332AbcGTXCa (ORCPT ); Wed, 20 Jul 2016 19:02:30 -0400 Date: Wed, 20 Jul 2016 19:02:28 -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: <20160720230228.GA19588@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <6e975d80-4077-fb8b-ec84-708e37c8e149@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 08:58:32AM +1000, Aleksa Sarai wrote: > I'm not sure what you mean by "steal". The user doing the migration owns the In the sense that the ancestor cgroup can be modified by one of its descendants even when that descendant doesn't have enough permission to modify the ancestor. > process, so I would argue that they aren't "stealing" anything. While a > higher level process might not know where precisely in the hierarchy the > process is, they'll know it that it must be a sub-cgroup of the one they > were put in (meaning the parent can still impose restrictions without any > issue). Hmmm... it's not just about the ownership of the process itself. If it had been, we wouldn't have bothered with permission model on cgroup hierarchy itself. It's also about who is allowed to modify a given cgroup and what you're proposing violates that. > If you want, we can make it so that an unprivileged user migrating processes > to a child cgroup only works if you're in the same cgroup namespace (and > have CAP_SYS_ADMIN in the pinned user namespace, etc). The current setup > would obviously still work, but you'd add a permission for users that just > want to be able to limit their own processes. IIRC we need to update > cgroup_procs_write_permission() anyway. By having the cgroup namespace > requirement, you'd definitely have to "own" the process in every sense of > the word I can imagine. Maybe I'm misunderstanding but I can't see how that would change the situation in a significant way. Thanks. -- tejun