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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
