All of lore.kernel.org
 help / color / mirror / Atom feed
From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Tejun Heo <tj@kernel.org>
Cc: Aleksa Sarai <asarai@suse.de>, Li Zefan <lizefan@huawei.com>,
	Johannes Weiner <hannes@cmpxchg.org>,
	Aleksa Sarai <cyphar@cyphar.com>,
	cgroups@vger.kernel.org, linux-kernel@vger.kernel.org,
	dev@opencontainers.org
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces
Date: Fri, 20 May 2016 12:09:10 -0400	[thread overview]
Message-ID: <1463760550.8091.13.camel@HansenPartnership.com> (raw)
In-Reply-To: <20160520160352.GC5632@htj.duckdns.org>

On Fri, 2016-05-20 at 09:03 -0700, Tejun Heo wrote:
> Hello, James.
> 
> On Fri, May 20, 2016 at 11:30:58AM -0400, James Bottomley wrote:
> > Given it's merge window time, I haven't yet had time to look at the
> > patch, but I can tell you why it (or something like it) is
> > necessary:
> > unprivileged containers need to be able to set up cgroups as well
> > as
> > namespaces, so we do need a way for the user ns owner to modify
> > cgroups
> > in their default configuration otherwise cgroups just won't fit
> > into
> > the unprivileged model.  Whether this should be through the cgroup
> > ns
> 
> That can be allowed by delegating a cgroup sub-hierarchy to the
> unpriviledged user.  Sub-cgroups created by that user will be owned 
> by that user.  IOW, if the owner of the cgroup hierarchy doesn't
> explicitly delegate the subtree, the unpriv user can't have the
> subtree.  This is true for regular use cases and shouldn't be
> different for namespaces.

The use case for unprivileged containers is that the end user should be
able to use them from the default configuration without and
administrator intervention (although there may be ways the admin can
prevent this if desired).  Your "deletage a cgroup sub-hierarchy"
requires admin intervention, so it's not yet a workflow that
unprivileged containers can use.

> 
> > is up for debate, as is how we should actually allow this to happen 
> > and what we should present to the user ns owner, but we do need a 
> > way to do this.
> > 
> > Delegation can't be through chmodding in this case because the user 
> > ns owner can't chmod something owned by init_user_ns root.
> 
> I still don't see why the existing mechanisms (including userns if
> delegation from inside a ns is necessary) aren't enough.  And even if
> we need something, I'd much prefer not to add a behavior which wildly
> deviates from the usual rules.

I think it's just different definitions.  If you take on our definition
of being able to set up a container without any admin intervention, do
you see our problem: we can't get the initial delegation of the
hierarchy.

James


  reply	other threads:[~2016-05-20 16:09 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-14  3:19 [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces Aleksa Sarai
2016-05-14  3:19 ` Aleksa Sarai
2016-05-14  3:19 ` [PATCH v4 1/2] cgroup: make cgroup.procs permissions userns-aware Aleksa Sarai
     [not found] ` <1463196000-13900-1-git-send-email-asarai-l3A5Bk7waGM@public.gmane.org>
2016-05-14  3:20   ` [PATCH v4 2/2] cgroup: implement subtree creation on copy_cgroup_ns() Aleksa Sarai
2016-05-14  3:20     ` Aleksa Sarai
2016-05-20 14:48   ` [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces Aleksa Sarai
2016-05-20 14:48     ` Aleksa Sarai
     [not found]     ` <573F23D0.2030500-l3A5Bk7waGM@public.gmane.org>
2016-05-20 15:22       ` Tejun Heo
2016-05-20 15:22         ` Tejun Heo
     [not found]         ` <20160520152244.GB5632-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-05-20 15:30           ` James Bottomley
2016-05-20 15:30             ` James Bottomley
     [not found]             ` <1463758258.8091.3.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-20 16:03               ` Tejun Heo
2016-05-20 16:03                 ` Tejun Heo
2016-05-20 16:09                 ` James Bottomley [this message]
2016-05-20 16:17                   ` Tejun Heo
     [not found]                     ` <20160520161759.GD5632-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-05-20 16:25                       ` James Bottomley
2016-05-20 16:25                         ` James Bottomley
     [not found]                         ` <1463761509.8091.19.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-20 16:29                           ` Aleksa Sarai
2016-05-20 16:29                             ` Aleksa Sarai
2016-05-20 16:53                         ` Tejun Heo
     [not found]                           ` <20160520165326.GE5632-piEFEHQLUPpN0TnZuCh8vA@public.gmane.org>
2016-05-20 17:28                             ` James Bottomley
2016-05-20 17:28                               ` James Bottomley
     [not found]                               ` <1463765326.8091.42.camel-d9PhHud1JfjCXq6kfMZ53/egYHeGw8Jk@public.gmane.org>
2016-05-20 17:49                                 ` Tejun Heo
2016-05-20 17:49                                   ` Tejun Heo
2016-05-28  5:12                                   ` Aleksa Sarai
2016-05-31 18:18                                     ` Tejun Heo
2016-05-20 17:33                             ` W. Trevor King
2016-05-20 17:33                               ` W. Trevor King
2016-05-20 17:33                         ` Aditya Kali
2016-05-20 17:50                           ` James Bottomley

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=1463760550.8091.13.camel@HansenPartnership.com \
    --to=james.bottomley@hansenpartnership.com \
    --cc=asarai@suse.de \
    --cc=cgroups@vger.kernel.org \
    --cc=cyphar@cyphar.com \
    --cc=dev@opencontainers.org \
    --cc=hannes@cmpxchg.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lizefan@huawei.com \
    --cc=tj@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.