Quoting Tejun Heo (tj@xxxxxxxxxx): > 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 -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
