On Tue, Dec 13, 2016 at 9:17 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: > On 12/13/2016 8:49 AM, John Stultz wrote: >> On Tue, Dec 13, 2016 at 8:39 AM, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> wrote: >>> On 12/13/2016 1:47 AM, Michael Kerrisk (man-pages) wrote: >>>> How about CAP_CGROUP_CONTROL or some such, with the idea that this >>>> might be a capability that allows the holder to step outside usual >>>> cgroup rules? At the moment, that capability would allow only one such >>>> step, but maybe there would be others in the future. >>> I agree, but want to put it more strongly. The granularity of >>> capabilities can never be fine enough for some people, and this >>> is an example of a case where you're going a bit too far. If the >>> use case is Android as you say, you don't need this. As my friends >>> on the far side of the aisle would say, "just write SELinux policy" >>> to correctly control access as required. >> So.. The trouble is that while selinux is good for restricting >> permissions, the in-kernel permission checks here are already too >> restrictive. > > Why did the original authors of cgroups make it that restrictive? > If there isn't a good reason, loosen it up. If there is a good > reason, then pay heed to it. That's what this patch is proposing. And I agree with Michael that the newly proposed cap was a bit to narrowly focused on my immediate use case, and broadening it to CGROUP_CONTROL is smart. Then that capability could be further restricted w/ selinux policy, as you suggest. thanks -john -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
