Re: [OFFLIST] status of devcg

Re: [OFFLIST] status of devcg

[Aristeu Rozanski]

On Wed, Jul 10, 2013 at 11:46:55AM -0700, Tejun Heo wrote:
> Just wondering whether you're working on implementing new hierarchical
> behavior on devcg.  If so, can you please share some details on how
> you're planning to do it?  Please feel free to add the relevant
> mailing lists when replying.

I did start, but still dealing with lots of company internal tasks so I
couldn't do much.

One of the ideas is to start changing (again) how the rules are processed
internally, moving away from the default policy + exceptions model to
an ordered set of rules like iptables:

	default: allow/deny
	allow block major 100-101, all minors
	deny char major 200, all minors
	...

That will solve most complex use cases the current model won't [1] but
the problem with this approach is that since it relies on order, merging
would be a problem, and it'd have test each parent all the way to / to
make sure the access is possible.

[1] One example of usage the current model won't solve:

	- by default deny everything
	- allow c,200,*
	- but deny c,200,100

The second idea, which is simpler, will reuse the current internal model
of default policy + exceptions and the idea in the initial patches of having
two lists in each cgroup: active policy+exceptions and locally set
policy+exceptions. This way for every change that happens in a parent (or
even change of parents when moving the cgroup around), the active
policy+exceptions will be regenerated.

In both cases, we do need a new userspace interface (although we can
still provide backwards compatibility with the old one).

Comments?

-- 
Aristeu

Re: [OFFLIST] status of devcg

[Daniel P. Berrange]

On Wed, Jul 10, 2013 at 03:50:02PM -0400, Aristeu Rozanski wrote:
> On Wed, Jul 10, 2013 at 11:46:55AM -0700, Tejun Heo wrote:
> > Just wondering whether you're working on implementing new hierarchical
> > behavior on devcg.  If so, can you please share some details on how
> > you're planning to do it?  Please feel free to add the relevant
> > mailing lists when replying.
> 
> I did start, but still dealing with lots of company internal tasks so I
> couldn't do much.
> 
> One of the ideas is to start changing (again) how the rules are processed
> internally, moving away from the default policy + exceptions model to
> an ordered set of rules like iptables:
> 
> 	default: allow/deny
> 	allow block major 100-101, all minors
> 	deny char major 200, all minors
> 	...
> 
> That will solve most complex use cases the current model won't [1] but
> the problem with this approach is that since it relies on order, merging
> would be a problem, and it'd have test each parent all the way to / to
> make sure the access is possible.
> 
> [1] One example of usage the current model won't solve:
> 
> 	- by default deny everything
> 	- allow c,200,*
> 	- but deny c,200,100
> 
> The second idea, which is simpler, will reuse the current internal model
> of default policy + exceptions and the idea in the initial patches of having
> two lists in each cgroup: active policy+exceptions and locally set
> policy+exceptions. This way for every change that happens in a parent (or
> even change of parents when moving the cgroup around), the active
> policy+exceptions will be regenerated.
> 
> In both cases, we do need a new userspace interface (although we can
> still provide backwards compatibility with the old one).
> 
> Comments?

FWIW, libvirt's usage of devcg is to deny all by default, allow major 136
(for all /dev/pts/*), followed by allow (major,minor) pair for each specific
whitelisted devices. As such we don't have anything that relies on ordering
of rules in devcg.

Regards,
Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

Re: [OFFLIST] status of devcg

[Tejun Heo]

On Thu, Jul 11, 2013 at 10:34:05AM +0100, Daniel P. Berrange wrote:
> FWIW, libvirt's usage of devcg is to deny all by default, allow major 136
> (for all /dev/pts/*), followed by allow (major,minor) pair for each specific
> whitelisted devices. As such we don't have anything that relies on ordering
> of rules in devcg.

I'd personally much prefer something very simple - allow all by
default, allow only the specified if explicitly specified.  I really
don't want full iptables like facility inside devcg.

Thanks.

-- 
tejun

Re: [OFFLIST] status of devcg

[Serge Hallyn]

Quoting Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org):
> On Thu, Jul 11, 2013 at 10:34:05AM +0100, Daniel P. Berrange wrote:
> > FWIW, libvirt's usage of devcg is to deny all by default, allow major 136
> > (for all /dev/pts/*), followed by allow (major,minor) pair for each specific
> > whitelisted devices. As such we don't have anything that relies on ordering
> > of rules in devcg.
> 
> I'd personally much prefer something very simple - allow all by
> default, allow only the specified if explicitly specified.  I really
> don't want full iptables like facility inside devcg.
> 
> Thanks.

FWIW lxc is also quite happy with the simple rules.

Is there something in particular you want to accomplish for which the
current rules do not suffice?

Re: [OFFLIST] status of devcg

[Tejun Heo]

Hello,

On Thu, Jul 11, 2013 at 11:05:32AM -0500, Serge Hallyn wrote:
> Is there something in particular you want to accomplish for which the
> current rules do not suffice?

Yeah, a cgroup changing its rules affecting the descendants
irreversibly, which is nasty and makes it tricky to implement
automation on top or implement proper cgroup migration, so I asked
Aristeu whether he could implement cleaner behavior for unified
hierarchy.

Thanks.

-- 
tejun

Re: [OFFLIST] status of devcg

[Tejun Heo]

On Thu, Jul 11, 2013 at 10:10:37AM -0700, Tejun Heo wrote:
> Hello,
> 
> On Thu, Jul 11, 2013 at 11:05:32AM -0500, Serge Hallyn wrote:
> > Is there something in particular you want to accomplish for which the
> > current rules do not suffice?
> 
> Yeah, a cgroup changing its rules affecting the descendants
> irreversibly, which is nasty and makes it tricky to implement
> automation on top or implement proper cgroup migration, so I asked
> Aristeu whether he could implement cleaner behavior for unified
> hierarchy.

Ooh, BTW, the other controller which has similar behavior is cpuset
and that one is gonna be updated too.

Thanks.

-- 
tejun

Re: [OFFLIST] status of devcg

[Serge Hallyn]

Quoting Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org):
> Hello,
> 
> On Thu, Jul 11, 2013 at 11:05:32AM -0500, Serge Hallyn wrote:
> > Is there something in particular you want to accomplish for which the
> > current rules do not suffice?
> 
> Yeah, a cgroup changing its rules affecting the descendants
> irreversibly, which is nasty and makes it tricky to implement
> automation on top or implement proper cgroup migration, so I asked
> Aristeu whether he could implement cleaner behavior for unified
> hierarchy.

Before I respond to that, could you please tell me precisely what
you mean by 'unified hierarchy'?  I thought it just meant all
controllers composed into one mount.  Maybe it means something
else.

-serge

Re: [OFFLIST] status of devcg

[Tejun Heo]

On Thu, Jul 11, 2013 at 02:12:06PM -0500, Serge Hallyn wrote:
> Before I respond to that, could you please tell me precisely what
> you mean by 'unified hierarchy'?  I thought it just meant all
> controllers composed into one mount.  Maybe it means something
> else.

Oh, it's gonna be a hierarchy which can dynamically enable / disable
controllers in sub-hierarchies, so it isn't just co-mounting
everything, which really wouldn't work for many use cases.  As some
controllers are outright hostile against being co-mounted and this is
basically gonna be v2 (or v1.1 whatever) of the itnerface, I'm trying
to weed out weird behaviors.

Thanks.

-- 
tejun

Re: [OFFLIST] status of devcg

[Serge E. Hallyn]

Quoting Tejun Heo (tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org):
> On Thu, Jul 11, 2013 at 02:12:06PM -0500, Serge Hallyn wrote:
> > Before I respond to that, could you please tell me precisely what
> > you mean by 'unified hierarchy'?  I thought it just meant all
> > controllers composed into one mount.  Maybe it means something
> > else.
> 
> Oh, it's gonna be a hierarchy which can dynamically enable / disable
> controllers in sub-hierarchies, so it isn't just co-mounting
> everything, which really wouldn't work for many use cases.  As some

I see.  (I'll let that sink in for a bit then look back at Aristeu's
email :)

> controllers are outright hostile against being co-mounted and this is
> basically gonna be v2 (or v1.1 whatever) of the itnerface, I'm trying
> to weed out weird behaviors.
> 
> Thanks.

Thanks

-serge