Messages in this thread | | | Date | Tue, 3 Mar 2015 21:08:52 -0800 (PST) | From | David Lang <> | Subject | Re: cgroup: status-quo and userland efforts |
| |
On Tue, 3 Mar 2015, Luke Leighton wrote:
>> I wrote about that many times, but here are two of the problems. >> >> * There's no way to designate a cgroup to a resource, because cgroup >> is only defined by the combination of who's looking at it for which >> controller. That's how you end up with tagging the same resource >> multiple times for different controllers and even then it's broken >> as when you move resources from one cgroup to another, you can't >> tell what to do with other tags. >> >> While allowing obscene level of flexibility, multiple hierarchies >> destroy a very fundamental concept that it *should* provide - that >> of a resource container. It can't because a "cgroup" is undefined >> under multiple hierarchies. > > ok, there is an alternative to hierarchies, which has precedent > (and, importantly, a set of userspace management tools as well as > existing code in the linux kernel), and it's the FLASK model which > you know as SE/Linux. > > whilst the majority of people view management to be "hierarchical" > (so there is a top dog or God process and everything trickles down > from that), this is viewed as such an anathema in the security > industry that someone came up with a formal specification for the > real-world way in which permissions are managed, and it's called the > FLASK model.
On this topic it's also worth reading Neil Brown's series of articles on this over at http://lwn.net/Articles/604609/ and why he concludes that having a single hierarchy for all resource types.
David Lang
| |