From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbbCDFJM (ORCPT ); Wed, 4 Mar 2015 00:09:12 -0500 Received: from mail.lang.hm ([64.81.33.126]:53351 "EHLO bifrost.lang.hm" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753887AbbCDFJJ (ORCPT ); Wed, 4 Mar 2015 00:09:09 -0500 Date: Tue, 3 Mar 2015 21:08:52 -0800 (PST) From: David Lang X-X-Sender: dlang@asgard.lang.hm To: Luke Leighton cc: linux-kernel@vger.kernel.org Subject: Re: cgroup: status-quo and userland efforts In-Reply-To: Message-ID: References: <20130406012159.GA17159@mtj.dyndns.org> <20130422214159.GG12543@htj.dyndns.org> <20130625000118.GT1918@mtj.dyndns.org> <20130626212047.GB4536@htj.dyndns.org> <20130627010427.GF4536@htj.dyndns.org> User-Agent: Alpine 2.02 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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