[lxc-devel] cgroup management daemon

[Tejun Heo]

Hello, Serge.

On Tue, Dec 03, 2013 at 06:03:44PM -0600, Serge Hallyn wrote:
> > As I communicated multiple times before, delegating write access to
> > control knobs to untrusted domain has always been a security risk and
> > is likely to continue to remain so.  Also, organizationally, a
> 
> Then that will need to be address with per-key blacklisting and/or
> per-value filtering in the manager.
> 
> Which is my way of saying:  can we please have a list of the security
> issues so we can handle them?  :)  (I've asked several times before
> but haven't seen a list or anyone offering to make one)

Unfortunately, for now, please consider everything blacklisted.  Yes,
it is true that some knobs should be mostly safe but given the level
of changes we're going through and the difficulty of properly auditing
anything for delegation to untrusted environment, I don't feel
comfortable at all about delegating through chown.  It is an
accidental feature which happened just because it uses filesystem as
its interface and it is no where near the top of the todo list.  It
has never worked properly and won't in any foreseeable future.

> > cgroup's control knobs belong to the parent not the cgroup itself.
> 
> After thinking awhile I think this makes perfect sense.  I haven't
> implemented set_value yet, and when I do I think I'll implement this
> guideline.

I'm kinda confused here.  You say *everything* is gonna go through the
manager and then talks about chowning directories.  Don't the two
conflict?

> > > Long-term we will want the cgroup manager to become more intelligent -
> > > to place its own limits on clients, to address cpu and device hotplug,
> > > etc.  Since we will not be doing that in the first prototype, the daemon
> > > will not keep any state about the clients.
> > 
> > Isn't the above conflicting with chowning control knobs?
> 
> Not sure what you mean by this.
> 
> To be clear what I'm talking about is having the client be able to say
> "grant 50% of cpus", then when more cpus are added, the actual cpuset
> gets recalculated.  This may well forever stay outside of the cgmanager
> scope.  It may be more appropriate to put that logic into the lmctfy
> layer.

Yes, something like that would be nice but if you give out raw access
to the control knobs by chowning them, I just don't see how that would
be implementable.  What am I missing here?

Thanks.

-- 
tejun