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]

Message-ID: <CALAqxLVz4WH5T7mjD1U5XG1pWQCJqsO2LWYcpJ+xDPjRb9QMig@mail.gmail.com>
Date:   Tue, 13 Dec 2016 08:08:16 -0800
From:   John Stultz <john.stultz@...aro.org>
To:     Michael Kerrisk <mtk.manpages@...il.com>
Cc:     lkml <linux-kernel@...r.kernel.org>, Tejun Heo <tj@...nel.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 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?

thanks
-john