[lxc-devel] cgroup management daemon

[Victor Marmol]

I thought we were going to use chown in the initial version to enforce the
ownership/permissions on the hierarchy. Only the cgroup manager has access
to the hierarchy, but it tries to access the hierarchy as the user that
sent the request. It was only meant to be a "for now" solution while the
real one rolls out. It may also have gotten thrown out since last I heard :)


On Tue, Dec 3, 2013 at 8:53 PM, Tim Hockin <thockin at google.com> wrote:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxcontainers.org/pipermail/lxc-devel/attachments/20131203/bfafabb0/attachment.html>