Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754181AbcJDTim (ORCPT ); Tue, 4 Oct 2016 15:38:42 -0400 Received: from mail-yw0-f196.google.com ([209.85.161.196]:33536 "EHLO mail-yw0-f196.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752617AbcJDTik (ORCPT ); Tue, 4 Oct 2016 15:38:40 -0400 Date: Tue, 4 Oct 2016 15:38:38 -0400 From: Tejun Heo To: John Stultz Cc: lkml , Li Zefan , Jonathan Corbet , cgroups@vger.kernel.org, Android Kernel Team , Rom Lemarchand , Colin Cross , Dmitry Shmidt , Todd Kjos , Christian Poetzsch , Amit Pundir , Serge Hallyn Subject: Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions Message-ID: <20161004193838.GH4205@htj.duckdns.org> References: <1475556090-6278-1-git-send-email-john.stultz@linaro.org> <20161004161630.GC4205@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.7.0 (2016-08-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1120 Lines: 33 Hello, John. On Tue, Oct 04, 2016 at 11:01:12AM -0700, John Stultz wrote: > So to make sure I understand your suggestion, you're suggesting the > cgroupfs files like: > cpuctrl/tasks, > cpuctrl/bg_non_interactive/tasks, > cpuset/foreground/tasks, > cpuset/background/tasks, > etc > use ACL permissions to specify the specific uids that can write to > them? I guess this would be conceptually similar to just setting the > owner to the system task, no? Though I'm not sure that would be Yeah, finer grained but essentially just giving write perms. > sufficient since it would still fail the > cgroup_procs_write_permission() checks. Or are you suggesting we add > extra logic to make the file owner uid as sufficient to change other > tasks? Hah, now I'm not sure how this is supposed to work inside a userns as it's checking against GLOBAL_ROOT_UID. cc'ing Serge. Serge, can you please have a look? But back on subject, yeah, I think a capability based approach is better here too. No idea how difficult it is to add a new CAP but I think it's worth trying. Can you please spin up a patch? Thanks! -- tejun