lkml.org 
[lkml]   [2016]   [Jul]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
Hello, Aleksa.

On Thu, Jul 21, 2016 at 08:58:32AM +1000, Aleksa Sarai wrote:
> I'm not sure what you mean by "steal". The user doing the migration owns the

In the sense that the ancestor cgroup can be modified by one of its
descendants even when that descendant doesn't have enough permission
to modify the ancestor.

> process, so I would argue that they aren't "stealing" anything. While a
> higher level process might not know where precisely in the hierarchy the
> process is, they'll know it that it must be a sub-cgroup of the one they
> were put in (meaning the parent can still impose restrictions without any
> issue).

Hmmm... it's not just about the ownership of the process itself. If
it had been, we wouldn't have bothered with permission model on cgroup
hierarchy itself. It's also about who is allowed to modify a given
cgroup and what you're proposing violates that.

> If you want, we can make it so that an unprivileged user migrating processes
> to a child cgroup only works if you're in the same cgroup namespace (and
> have CAP_SYS_ADMIN in the pinned user namespace, etc). The current setup
> would obviously still work, but you'd add a permission for users that just
> want to be able to limit their own processes. IIRC we need to update
> cgroup_procs_write_permission() anyway. By having the cgroup namespace
> requirement, you'd definitely have to "own" the process in every sense of
> the word I can imagine.

Maybe I'm misunderstanding but I can't see how that would change the
situation in a significant way.

Thanks.

--
tejun

\
 
 \ /
  Last update: 2016-07-21 01:41    [W:0.077 / U:0.228 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site