linux-kernel - Re: [PATCH v5] cgroup: Add new capability to allow a process to migrate other tasks between cgroups

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Tue, 13 Dec 2016 10:47:19 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Tejun Heo <tj@...nel.org>
Cc:     Michael Kerrisk <mtk.manpages@...il.com>,
        lkml <linux-kernel@...r.kernel.org>,
        Li Zefan <lizefan@...wei.com>,
        Jonathan Corbet <corbet@....net>,
        "open list:CONTROL GROUP (CGROUP)" <cgroups@...r.kernel.org>,
        Android Kernel Team <kernel-team@...roid.com>,
        Rom Lemarchand <romlem@...roid.com>,
        Colin Cross <ccross@...roid.com>,
        Dmitry Shmidt <dimitrysh@...gle.com>,
        Todd Kjos <tkjos@...gle.com>,
        Christian Poetzsch <christian.potzsch@...tec.com>,
        Amit Pundir <amit.pundir@...aro.org>,
        Dmitry Torokhov <dmitry.torokhov@...il.com>,
        Kees Cook <keescook@...omium.org>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Andy Lutomirski <luto@...capital.net>,
        Linux API <linux-api@...r.kernel.org>
Subject: Re: [PATCH v5] cgroup: Add new capability to allow a process to
 migrate other tasks between cgroups

On Tue, Dec 13, 2016 at 10:40 AM, Tejun Heo <tj@...nel.org> wrote:
> Hello,
>
> On Tue, Dec 13, 2016 at 08:08:16AM -0800, John Stultz wrote:
>> On Tue, Dec 13, 2016 at 1:47 AM, Michael Kerrisk (man-pages)
>> <mtk.manpages@...il.com> wrote:
>> > On 13 December 2016 at 02:39, John Stultz <john.stultz@...aro.org> wrote:
>> > So, back to the discussion of silos. I understand the argument for
>> > wanting a new silo. But, in that case can we at least try not to make
>> > it a single-use silo?
>> >
>> > 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.
>>
>> This sounds reasonable to me. Tejun/Andy: Objections?
>
> Control group control?  The word control has a specific meaning for
> cgroups and that second control doesn't make much sense to me.

But this would go against the long tradition of RAS syndrome and
things like "struct task_struct".  :)

>  Given
> how this is mostly to patch up a hole in v1's delegation model and how
> migration operations are different from others, I doubt that we will
> end up overloading it.  Maybe just CAP_CGROUP?

Sounds ok to me.

thanks
-john