linux-kernel - Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants

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: <20160720231949.GB19588@mtj.duckdns.org>
Date:	Wed, 20 Jul 2016 19:19:49 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Aleksa Sarai <asarai@...e.de>
Cc:	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,
	James Bottomley <James.Bottomley@...senpartnership.com>
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for
 direct descendants

Hello, Aleksa.

On Thu, Jul 21, 2016 at 09:18:59AM +1000, Aleksa Sarai wrote:
> I feel like the permission model makes sense in certain cases (the common
> ancestor restriction, as well as the ability for a parent to apply limits to
> children by setting its own limits). Neither of those are violated (if you
> read the commit that introduced the common ancestor restriction).
>
> Maybe if you give me a usecase of when it might be important that a process
> must not be able to move to a sub-cgroup of its current one, I might be able
> to understand your concerns? From my perspective, I think that's actually
> quite useful.

cgroup is used to keep track of which processes belong where and
allowing processes to be moved out of its cgroup like this would be
surprising to say the least.

> > Maybe I'm misunderstanding but I can't see how that would change the
> > situation in a significant way.
> 
> Well, it would avoid the issue of a process being moved against *its* will.
> The process would have to be complicit in joining (or unsharing) a cgroup
> namespace. I'm not sure I really agree with the argument that a higher level
> process should be able to stop a process from imposing more *stringent*
> limits on itself if the process is complicit in setting those limits (see
> above).
> 
> The reason I'm doing this is so that we might be able to _practically_ use
> cgroups as an unprivileged user (something that will almost certainly be
> useful to not just the container crowd, but people also planning on using
> cgroups as advanced forms of rlimits).

I don't get why we need this fragile dance with permissions at all
when the same functionality can be achieved by delegating explicitly.

Thanks.

-- 
tejun