All of lore.kernel.org
 help / color / mirror / Atom feed
From: Aristeu Rozanski <aris-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org>
Cc: Serge Hallyn
	<serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>,
	cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org,
	"Eric W. Biederman"
	<ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
Subject: Re: Why does devices cgroup check for CAP_SYS_ADMIN explicitly?
Date: Tue, 6 Nov 2012 11:12:39 -0500	[thread overview]
Message-ID: <20121106161238.GP14789@redhat.com> (raw)
In-Reply-To: <20121106154105.GD30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>

On Tue, Nov 06, 2012 at 07:41:05AM -0800, Tejun Heo wrote:
> On Tue, Nov 06, 2012 at 09:30:32AM -0600, Serge Hallyn wrote:
> > > So, you don't really have any actual use case for the explicit CAP_*
> > > checks, right?
> > 
> > No, especially since we will now have user namespaces.
> > 
> > We will want to be able to strictly enforce hierarchical limits - i.e.
> > allow uid 100000 (which is uid 0 in the container) to change cgroup
> > settings, but never exceed limits set on the parent directory.  IIUC
> > you are working toward anyway with the general hierarchy work? (thanks
> > for that).
> 
> Yeah, I'm working toward that but I'm not sure it would mean that
> containers would be able to directly bind mount cgroupfs subdirectory
> and have free reign on it.  Maybe such thing can be made to work but I
> would be much more comfortable having something inbetween for
> impedance matching (in access policies, root cgroup behavior matching,
> whatnot).  So, the functionality will be there but it probably would
> need something inbetween if you wanna give containers control over its
> own cgroup hierarchy.
> 
> There are some issues tho.  As it currently stands, devices cgroup
> inherits configuration rather than enforcing hierarchy while checking
> for access permission.  This means that changes in an ancestor have to
> be propagated downwards and *update* configurations of descendants,
> which is what I'm working on but it can be confusing for someone
> inside the container.  Without breaking compatibility, I don't see any
> other way out tho.  I suppose it's something we'll have to live with.

yes, but most of the changes will happen before the containers start.
I've been working in a patchset (as promised) and it propagates down the
changes and also keep 'local' rules. everytime a parent change
something, the local rules are re-evaluated and reapplied if they're
still valid.

-- 
Aristeu

  parent reply	other threads:[~2012-11-06 16:12 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-06  2:38 Why does devices cgroup check for CAP_SYS_ADMIN explicitly? Tejun Heo
     [not found] ` <20121106023845.GI19354-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 11:58   ` Eric W. Biederman
     [not found]     ` <877gpzrlir.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 14:48       ` Tejun Heo
2012-11-06 14:48       ` Tejun Heo
2012-11-06 15:01       ` Serge Hallyn
2012-11-06 15:06         ` Tejun Heo
2012-11-06 15:06         ` Tejun Heo
     [not found]           ` <20121106150639.GB30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 15:30             ` Serge Hallyn
2012-11-06 15:30             ` Serge Hallyn
2012-11-06 15:41               ` Tejun Heo
     [not found]                 ` <20121106154105.GD30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 16:12                   ` Aristeu Rozanski
2012-11-06 16:12                   ` Aristeu Rozanski [this message]
2012-11-06 15:41               ` Tejun Heo
2012-11-06 15:34             ` Eric W. Biederman
     [not found]               ` <871ug6rbio.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 15:43                 ` Tejun Heo
     [not found]                   ` <20121106154320.GE30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 16:10                     ` Eric W. Biederman
     [not found]                       ` <87sj8mogpp.fsf-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org>
2012-11-06 16:52                         ` Tejun Heo
     [not found]                           ` <20121106165246.GF30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 17:31                             ` Serge Hallyn
2012-11-06 17:31                             ` Serge Hallyn
2012-11-06 17:38                               ` Tejun Heo
2012-11-06 17:38                               ` Tejun Heo
     [not found]                                 ` <20121106173823.GK30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 17:41                                   ` Tejun Heo
     [not found]                                     ` <20121106174130.GL30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 18:02                                       ` Serge Hallyn
2012-11-06 18:08                                         ` Tejun Heo
2012-11-06 18:08                                         ` Tejun Heo
2012-11-06 18:02                                       ` Serge Hallyn
2012-11-06 18:12                                   ` Serge Hallyn
2012-11-06 18:12                                   ` Serge Hallyn
2012-11-06 18:16                                     ` Tejun Heo
2012-11-06 18:16                                     ` Tejun Heo
     [not found]                                       ` <20121106181623.GO30069-9pTldWuhBndy/B6EtB590w@public.gmane.org>
2012-11-06 18:25                                         ` Serge Hallyn
2012-11-06 16:10                     ` Eric W. Biederman
2012-11-06 15:45                 ` Serge Hallyn
2012-11-06 15:45                 ` Serge Hallyn
2012-11-06 15:34             ` Eric W. Biederman
2012-11-06 15:01       ` Serge Hallyn
  -- strict thread matches above, loose matches on Subject: below --
2012-11-06  2:38 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=20121106161238.GP14789@redhat.com \
    --to=aris-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=cgroups-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org \
    --cc=ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org \
    --cc=serge.hallyn-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org \
    --cc=tj-DgEjT+Ai2ygdnm+yROfE0A@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 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.