From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Serge E. Hallyn" Subject: Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups Date: Tue, 4 Oct 2016 23:25:29 -0500 Message-ID: <20161005042529.GA30929@mail.hallyn.com> References: <1475626874-22949-1-git-send-email-john.stultz@linaro.org> <20161005003833.GA29239@mail.hallyn.com> Mime-Version: 1.0 Return-path: Content-Disposition: inline In-Reply-To: Sender: cgroups-owner-u79uwXL29TY76Z2rM5mHXA@public.gmane.org List-ID: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: John Stultz Cc: "Serge E. Hallyn" , lkml , Tejun Heo , Li Zefan , Jonathan Corbet , cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir On Tue, Oct 04, 2016 at 08:00:18PM -0700, John Stultz wrote: > On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn wrote: > > Quoting John Stultz (john.stultz-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org): > >> So this patch, as suggested by Tejun, simply adds a new process > >> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking > > > > So realistically, what all can this mean? Freezing tasks, changing > > cpu/memory limits, changing network and disk throughput, forbid forking, > > and (most importantly) forbid access to certain devices. > > > > I think that's all ok. (And we still separately check for inode write > > perms.) > > Sounds good. > > > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since > > otherwise a host-root task effectively cannot drop this capability. > > Is this ok to leave for a separate patch? Yeah. And I'm not sure whether Tejun would object to that idea. > > Acked-by: Serge Hallyn > > Thanks for the review! > > Unless there's other feedback, I'll sit on this until the merge window > is over and then resubmit for consideration for 4.10. > > thanks > -john From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751918AbcJEEZd (ORCPT ); Wed, 5 Oct 2016 00:25:33 -0400 Received: from h2.hallyn.com ([78.46.35.8]:53386 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750803AbcJEEZc (ORCPT ); Wed, 5 Oct 2016 00:25:32 -0400 Date: Tue, 4 Oct 2016 23:25:29 -0500 From: "Serge E. Hallyn" To: John Stultz Cc: "Serge E. Hallyn" , lkml , Tejun Heo , Li Zefan , Jonathan Corbet , cgroups@vger.kernel.org, Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir Subject: Re: [RFC][PATCH] cgroup: Add new capability to allow a process to migrate other tasks between cgroups Message-ID: <20161005042529.GA30929@mail.hallyn.com> References: <1475626874-22949-1-git-send-email-john.stultz@linaro.org> <20161005003833.GA29239@mail.hallyn.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Oct 04, 2016 at 08:00:18PM -0700, John Stultz wrote: > On Tue, Oct 4, 2016 at 5:38 PM, Serge E. Hallyn wrote: > > Quoting John Stultz (john.stultz@linaro.org): > >> So this patch, as suggested by Tejun, simply adds a new process > >> capability flag (CAP_CGROUP_MIGRATE_TASK), and uses it when checking > > > > So realistically, what all can this mean? Freezing tasks, changing > > cpu/memory limits, changing network and disk throughput, forbid forking, > > and (most importantly) forbid access to certain devices. > > > > I think that's all ok. (And we still separately check for inode write > > perms.) > > Sounds good. > > > If anything I'd say the GLOBAL_ROOT_UID check could be taken out since > > otherwise a host-root task effectively cannot drop this capability. > > Is this ok to leave for a separate patch? Yeah. And I'm not sure whether Tejun would object to that idea. > > Acked-by: Serge Hallyn > > Thanks for the review! > > Unless there's other feedback, I'll sit on this until the merge window > is over and then resubmit for consideration for 4.10. > > thanks > -john