Re: [RFC][PATCH 0/2] Another pass at Android style loosening of cgroup attach permissions
From: John Stultz
Date: Tue Oct 04 2016 - 15:46:30 EST
On Tue, Oct 4, 2016 at 12:38 PM, Tejun Heo <tj@xxxxxxxxxx> wrote:
> 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:
>> 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
> 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?
Ok. I'll respin this introducing and using a new CAP value.
That said, while CAP_SYS_NICE seems a bit overloaded here, it doesn't
conceptually have that much friction for use with cpuset and cpuctrl
(from the man page: http://man7.org/linux/man-pages/man7/capabilities.7.html )
* Raise process nice value (nice(2), setpriority(2)) and
change the nice value for arbitrary processes;
* set real-time scheduling policies for calling process, and
set scheduling policies and priorities for arbitrary
processes (sched_setscheduler(2), sched_setparam(2),
* set CPU affinity for arbitrary processes
* set I/O scheduling class and priority for arbitrary
* apply migrate_pages(2) to arbitrary processes and allow
processes to be migrated to arbitrary nodes;
* apply move_pages(2) to arbitrary processes;
* use the MPOL_MF_MOVE_ALL flag with mbind(2) and
If you can tweak nice value and set realtime scheduling policy that
really seems to me just as invasive as what moving tasks between the
cpuctrl and cpuset cgroups could do.