[lxc-devel] cgroup management daemon

[Tim Hockin]

If this daemon works as advertised, we will explore moving all write
traffic to use it.  I still have concerns that this can't handle read
traffic at the scale we need.

Tejun,  I am not sure why chown came back into the conversation.  This
is a replacement for that.

On Tue, Dec 3, 2013 at 6:31 PM, Serge Hallyn <serge.hallyn at ubuntu.com> wrote:
> Quoting Tejun Heo (tj at kernel.org):
>> 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?
>
> No.  I expect the user - except in the google case - to either have
> access to no cgroupfs mounts, or readonly mounts.
>
> -serge