linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Tejun Heo <tj@kernel.org>
To: Aleksa Sarai <asarai@suse.de>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	"Serge E. Hallyn" <serge.hallyn@ubuntu.com>,
	Aditya Kali <adityakali@google.com>,
	Chris Wilson <chris@chris-wilson.co.uk>,
	linux-kernel@vger.kernel.org, cgroups@vger.kernel.org,
	Christian Brauner <cbrauner@suse.de>,
	dev@opencontainers.org,
	James Bottomley <James.Bottomley@hansenpartnership.com>
Subject: Re: [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants
Date: Wed, 20 Jul 2016 19:02:28 -0400	[thread overview]
Message-ID: <20160720230228.GA19588@mtj.duckdns.org> (raw)
In-Reply-To: <6e975d80-4077-fb8b-ec84-708e37c8e149@suse.de>

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

  reply	other threads:[~2016-07-20 23:02 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-18 16:18 [PATCH v1 0/3] cgroup: allow for unprivileged management Aleksa Sarai
2016-07-18 16:18 ` [PATCH v1 1/3] kernfs: add support for custom per-sb permission hooks Aleksa Sarai
2016-07-18 16:18 ` [PATCH v1 2/3] cgroup: allow for unprivileged subtree management Aleksa Sarai
2016-07-20 15:45   ` Tejun Heo
2016-07-20 22:59     ` Aleksa Sarai
2016-07-18 16:18 ` [PATCH v1 3/3] cgroup: relax common ancestor restriction for direct descendants Aleksa Sarai
2016-07-20 15:51   ` Tejun Heo
2016-07-20 22:58     ` Aleksa Sarai
2016-07-20 23:02       ` Tejun Heo [this message]
2016-07-20 23:18         ` Aleksa Sarai
2016-07-20 23:19           ` Tejun Heo
2016-07-21  7:49             ` Aleksa Sarai
2016-07-21 14:33               ` Serge E. Hallyn
2016-07-21 14:37                 ` Aleksa Sarai
2016-07-21 15:01                   ` Tejun Heo
2016-07-21 15:09                   ` Serge E. Hallyn
2016-07-21 14:51                 ` James Bottomley
2016-07-21 14:59                   ` Tejun Heo
2016-07-21 15:07                     ` Aleksa Sarai
2016-07-21 15:04                       ` Tejun Heo
2016-07-21 14:52               ` Tejun Heo
2016-07-21 15:04                 ` James Bottomley
2016-07-21 15:07                   ` Tejun Heo
2016-07-21 15:16                     ` James Bottomley
2016-07-21 15:26                       ` Tejun Heo
2016-07-21 15:34                         ` James Bottomley
2016-07-21 15:50                           ` Tejun Heo
2016-07-21 18:16                             ` James Bottomley
2016-07-21 21:06                               ` Tejun Heo
2016-07-22  8:30                             ` Aleksa Sarai
2016-07-25 18:38                               ` Tejun Heo
2016-07-25 22:54                                 ` Serge E. Hallyn
2016-07-22  8:24                     ` Aleksa Sarai
2016-07-25 18:44                       ` Tejun Heo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20160720230228.GA19588@mtj.duckdns.org \
    --to=tj@kernel.org \
    --cc=James.Bottomley@hansenpartnership.com \
    --cc=adityakali@google.com \
    --cc=asarai@suse.de \
    --cc=cbrauner@suse.de \
    --cc=cgroups@vger.kernel.org \
    --cc=chris@chris-wilson.co.uk \
    --cc=dev@opencontainers.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=serge.hallyn@ubuntu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).