[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4bc13b20-9e8f-f43c-27aa-df5ec981762e@suse.de>
Date: Fri, 22 Jul 2016 01:07:13 +1000
From: Aleksa Sarai <asarai@...e.de>
To: Tejun Heo <tj@...nel.org>,
James Bottomley <James.Bottomley@...senPartnership.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Li Zefan <lizefan@...wei.com>,
Johannes Weiner <hannes@...xchg.org>,
"Serge E. Hallyn" <serge.hallyn@...ntu.com>,
Aditya Kali <adityakali@...gle.com>,
Chris Wilson <chris@...is-wilson.co.uk>,
linux-kernel@...r.kernel.org, cgroups@...r.kernel.org,
Christian Brauner <cbrauner@...e.de>, dev@...ncontainers.org
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for
direct descendants
>> I have heard
>>
>> * it would give power to move other tasks to more rigid constraints.
>> To which the answer is only to allow movememnt of tasks in the
>> current cgroupns
>> * It violates the permissions delegation model. This one doesn't
>> really make too much sense to me: in the same way the userns is root
>> in its own domain, cgroups ns is effective root for the restricted
>> cgroups (and only for processes within its ns).
>>
>> Perhaps the question should be asked the other way around: if we were
>> explicitly delegating permission to every user in the system to set up
>> their own sub cgroups, how would you advise it be done?
>
> Coordinate in userspace. Request whatever is managing the cgroup
> hierarchy to set up delegation. It's not like permission model is
> fully contained in kernel on modern systems anyway.
My experience with certain systemdaemons' cgroup handling doesn't
inspire confidence :/ (from the runC side, we've had nothing but
issues). Also, how do you even boot into a cgroupv2 system with systemd
(I started backporting patches to openSUSE, but it's still not booting)?
--
Aleksa Sarai
Software Engineer (Containers)
SUSE Linux GmbH
https://www.cyphar.com/
Powered by blists - more mailing lists