Message-ID: <20160721150943.GB6382@mail.hallyn.com>
Date:	Thu, 21 Jul 2016 10:09:43 -0500
From:	"Serge E. Hallyn" <serge@...lyn.com>
To:	Aleksa Sarai <asarai@...e.de>
Cc:	"Serge E. Hallyn" <serge@...lyn.com>, Tejun Heo <tj@...nel.org>,
	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

Quoting Aleksa Sarai (asarai@...e.de):
> >>>>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.
> >>
> >>Would you find it acceptable if we added a bit that would make this
> >>not happen (you could specify that a cgroup should not allow a
> >>process to move itself to a sub-cgroup)? Or an aggregate
> >>cgroup.procs that gives you all of the processes in the entire
> >>branch of the tree? Surely this is something that can be fixed
> >>without unnecessarily restricting users from doing useful things.
> >>
> >>>>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.
> >>
> >>The key words being "unprivileged user". Currently, if I am a
> >>regular user on a system and I want to use the freezer cgroup to
> >>pause a process I am running, I have to *go to the administrator and
> >>ask them to give me permission to do that*. Why is that necessary? I
> >
> >Ths is of course solvable using something like libpam-cgfs or
> >libpam-cgm (and others).  Since this sounds like a question of
> >policy, not mechanism, userspace seems like the right place.  Is
> >there a downside to that (or, as Tejun put it, "delegating explicitly")?
> 
> Having a PAM module requires getting an administrator to install the
> PAM module (and also presumably audit it, not to mention convincing
> them that your requirement to use containers are significant enough

Right, but that's also the upside.  Just like user namespaces, it *is*
possible that there remain exploitable situations when cgroups are
delegated, and it is up to the admin, not the user, to gauge how
averse they are to that risk.

(Fwiw obviously I am very sympathetic to your goals :)

> for them to do any work). It's the same problem IMO. I understand
> that LXC allows you to do this, but it requires that you get an
> administrator to *install* and support LXC (as well as the
> shadow-utils setuid binaries too). There are cases where you don't
> have the freedom to do that, and also "just get someone to give you
> privileges temporarily" is again punting on the problem.
> 
> -- 
> Aleksa Sarai
> Software Engineer (Containers)
> SUSE Linux GmbH
> https://www.cyphar.com/

Powered by blists - more mailing lists