Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754167AbcJDUSo (ORCPT ); Tue, 4 Oct 2016 16:18:44 -0400 Received: from h2.hallyn.com ([78.46.35.8]:42402 "EHLO h2.hallyn.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752901AbcJDUSn (ORCPT ); Tue, 4 Oct 2016 16:18:43 -0400 Date: Tue, 4 Oct 2016 15:18:40 -0500 From: "Serge E. Hallyn" To: Tejun Heo Cc: John Stultz , lkml , 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 0/2] Another pass at Android style loosening of cgroup attach permissions Message-ID: <20161004201840.GA27018@mail.hallyn.com> References: <1475556090-6278-1-git-send-email-john.stultz@linaro.org> <20161004161630.GC4205@htj.duckdns.org> <20161004193838.GH4205@htj.duckdns.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161004193838.GH4205@htj.duckdns.org> 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 Content-Length: 1552 Lines: 47 Quoting Tejun Heo (tj@kernel.org): > 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? Hi, thanks for the cc, how about changing the GLOBAL_ROOT_UID check with a targeted capability check, like if (!ns_capable(tcred->user_ns, CAP_SYS_NICE) && !uid_eq(cred->euid, tcred->uid) && !uid_eq(cred->euid, tcred->suid)) ret = -EACCES; where the actual capability to use may require some thought. > 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