Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934650AbcLMSrK (ORCPT ); Tue, 13 Dec 2016 13:47:10 -0500 Received: from mail-yb0-f195.google.com ([209.85.213.195]:34335 "EHLO mail-yb0-f195.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934593AbcLMSrG (ORCPT ); Tue, 13 Dec 2016 13:47:06 -0500 Date: Tue, 13 Dec 2016 13:47:03 -0500 From: Tejun Heo To: Casey Schaufler Cc: John Stultz , Michael Kerrisk , lkml , Li Zefan , Jonathan Corbet , "open list:CONTROL GROUP (CGROUP)" , Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir , Dmitry Torokhov , Kees Cook , "Serge E . Hallyn" , Andy Lutomirski , Linux API Subject: Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups Message-ID: <20161213184703.GB17672@htj.duckdns.org> References: <1481593143-18756-1-git-send-email-john.stultz@linaro.org> <221e80bd-3d99-6c35-dcd3-b2547f0abb11@schaufler-ca.com> <4c60e1be-c00a-5f26-f5de-7d32b9cb0f62@schaufler-ca.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.1 (2016-10-04) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 984 Lines: 25 Hello, Casey. On Tue, Dec 13, 2016 at 10:32:14AM -0800, Casey Schaufler wrote: > > The trouble is that CAP_SYS_NICE or _RESOURCE (which was tried in an > > earlier version of this patch) aren't necessarily appropriate for > > non-android systems. See Andy's objection here: > > https://lkml.org/lkml/2016/11/8/946 > > Then we need to see what those as-yet-unimplemented systems > require and how to address them. I don't think that taking > the "someone might want it" approach is really appropriate. I understands that there can be reservations regarding adding a new CAP but this isn't about someone possibly wanting it in the future. It's more about overloading existing CAPs leading to permitting unintended operations. e.g. ppl who've been delegating CAP_SYS_RESOURCES would automatically end up delegating cgroup organization without intending so. Using an existing cap would have been nice but it just doesn't look like we have a good one to overload. Thanks. -- tejun