Quoting Tejun Heo (t...@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 ------------------------------------------------------------------------------ Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk _______________________________________________ lxc-devel mailing list lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
