public inbox for cgroups@vger.kernel.org
 help / color / mirror / Atom feed
From: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
To: Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Cc: cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Li Zefan <lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>,
	Kay Sievers <kay.sievers-tD+1rO4QERM@public.gmane.org>,
	Lennart Poettering
	<mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.org>
Subject: Re: [PATCH 0/4] devcg: Store local settings for each device cgroup
Date: Fri, 16 Aug 2013 11:47:57 -0400	[thread overview]
Message-ID: <20130816154757.GG2505@htj.dyndns.org> (raw)
In-Reply-To: <20130816152025.GC7878-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>

Hello, Aristeu.

On Fri, Aug 16, 2013 at 11:20:26AM -0400, Aristeu Rozanski wrote:
> > e.g. if a cgroup will be allowed to be moved to another position in
> > the hierarchy, the cgroup shouldn't change its configuration across
> > such migration, right?  If so, we'd be allowing creating a cgroup
> > outside the hierarchy with any configuration moving it under another
> > while disallowing creating it under there and creating the same
> > configuration, which would be an outright buggy behavior.
> 
> Hm, then I think I got the requirements wrong. On my understanding you
> cannot have a cgroup with more access than its parent. And the reason
> for that is at that time the idea of having a container able to control
> its own hierarchy was valid.

Oh yes, sure, a descendant shouldn't have access to devices which
aren't allowed by its ancestors but that doesn't mean it can't have a
rule to allow such access.  It just wouldn't make any difference at
that point.  If the ancestors later change the configuration such that
the device is allowed, the cgroup will have access to that
automatically.  Rules configured and rules being applied need to be
distinguished and the latter doesn't need to affect the former.

> The way it is right now, when moved, a cgroup would have its active
> rules re-checked for permission and it'd be made an attempt to apply
> local rules if the new parent allows it.

Yeah, that's the correct behavior, if I'm not misunderstanding you,
but to be consistent we also need to allow creating rules which allow
devices which aren't allowed by ancestors.  It won't be applicable at
rule creation but may later become effective later on.

Thanks a lot for working on this!

-- 
tejun

  parent reply	other threads:[~2013-08-16 15:47 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-08-15 15:34 [PATCH 0/4] devcg: Store local settings for each device cgroup aris-H+wXaHxf7aLQT0dZR+AlfA
     [not found] ` <1376580854-30929-1-git-send-email-aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-15 15:34   ` [PATCH 1/4] devcg: move behavior and exceptions into its own structure aris-H+wXaHxf7aLQT0dZR+AlfA
2013-08-15 15:34   ` [PATCH 2/4] devcg: make dev_exception_ functions to use lists aris-H+wXaHxf7aLQT0dZR+AlfA
2013-08-15 15:34   ` [PATCH 3/4] devcg: save locally saved settings aris-H+wXaHxf7aLQT0dZR+AlfA
2013-08-15 15:34   ` [PATCH 4/4] devcg: try to reapply local settings aris-H+wXaHxf7aLQT0dZR+AlfA
2013-08-15 19:59   ` [PATCH 0/4] devcg: Store local settings for each device cgroup Tejun Heo
     [not found]     ` <20130815195941.GA10977-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-08-15 20:48       ` Aristeu Rozanski
     [not found]         ` <20130815204804.GO7878-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-15 21:09           ` Tejun Heo
     [not found]             ` <20130815210937.GB10977-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2013-08-16 15:20               ` Aristeu Rozanski
     [not found]                 ` <20130816152025.GC7878-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-16 15:47                   ` Tejun Heo [this message]
     [not found]                     ` <20130816154757.GG2505-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-08-16 16:02                       ` Aristeu Rozanski
     [not found]                         ` <20130816160204.GE7878-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-08-16 16:09                           ` Tejun Heo
     [not found]                             ` <20130816160950.GH2505-Gd/HAXX7CRxy/B6EtB590w@public.gmane.org>
2013-08-19  2:53                               ` Li Zefan
     [not found]                                 ` <52118892.7050909-hv44wF8Li93QT0dZR+AlfA@public.gmane.org>
2013-08-19 13:38                                   ` Aristeu Rozanski
2013-08-19 17:12                                   ` Serge E. Hallyn

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=20130816154757.GG2505@htj.dyndns.org \
    --to=tj-dgejt+ai2ygdnm+yrofe0a@public.gmane.org \
    --cc=aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=kay.sievers-tD+1rO4QERM@public.gmane.org \
    --cc=lizefan-hv44wF8Li93QT0dZR+AlfA@public.gmane.org \
    --cc=mzxreary-uLTowLwuiw4b1SvskN2V4Q@public.gmane.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox