Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 26 Aug 2016 11:50:26 -0400
From: Tejun Heo <>
To: Andy Lutomirski <>
Cc: Mickaël Salaün <>,
	LKML <>,
	Alexei Starovoitov <>, Arnd Bergmann <>,
	Casey Schaufler <>,
	Daniel Borkmann <>,
	Daniel Mack <>,
	David Drysdale <>,
	"David S . Miller" <>,
	Elena Reshetova <>,
	James Morris <>,
	Kees Cook <>, Paul Moore <>,
	Sargun Dhillon <>,
	"Serge E . Hallyn" <>,
	Will Drewry <>,
	Kernel Hardening <>,
	Linux API <>,
	LSM List <>,
	Network Development <>,
	"open list:CONTROL GROUP (CGROUP)" <>
Subject: Re: [RFC v2 09/10] landlock: Handle cgroups


On Fri, Aug 26, 2016 at 07:20:35AM -0700, Andy Lutomirski wrote:
> > This is simply the action of changing the owner of cgroup sysfs files to
> > allow an unprivileged user to handle them (cf. Documentation/cgroup-v2.txt)
> As far as I can tell, Tejun and systemd both actively discourage doing
> this.  Maybe I misunderstand.  But in any event, the admin giving you

Please refer to "2-5. Delegation" of Documentation/cgroup-v2.txt.
Delegation on v1 is broken on both core and specific controller
behaviors and thus discouraged.  On v2, delegation should work just

I haven't looked in detail but in general I'm not too excited about
layering security mechanism on top of cgroup.  Maybe it makes some
sense when security domain coincides with resource domains but at any
rate please keep me in the loop.



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.