linux-kernel - Re: cgroup: status-quo and userland efforts

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 3 Mar 2015 22:08:10 +0000 (UTC)
From:	Luke Leighton <lkcl@...l.net>
To:	linux-kernel@...r.kernel.org
Subject: Re: cgroup: status-quo and userland efforts

Tejun Heo <tj@...> writes:

> 
> Hello, Serge.
> 
> On Thu, Jun 27, 2013 at 08:22:06AM -0500, Serge Hallyn wrote:
> > At some point (probably soon) we might want to talk about a standard API
> > for these things.  However I think it will have to come in the form of
> > a standard library, which knows to either send requests over dbus to
> > systemd, or over /dev/cgroup sock to the manager.
> 
> Yeah, eventually, I think we'll have a standardized way to configure
> resource distribution in the system.  Maybe we'll agree on a
> standardized dbus protocol or there will be library, I don't know;
> however, whatever form it may be in, it abstraction level should be
> way higher than that of direct cgroupfs access.  It's way too low
> level and very easy to end up in a complete nonsense configuration.

 just because it sounds easy to end up in a complete nonsense
 configuration does not mean that the entire API should be abandoned.

 instead, it sounds to me like there should be explicit policies
 (taking a leaf out of SE/Linux's book) on what is and is not
 permitted.

 i think you'll find that that is much more acceptable [to have
 explicit policy files which define what can and can't be done].

 it then becomes possible to define "sensible and sane" default
 policies for the average situation, whilst also allowing for more
 complex cases to be created by those people who really really
 know what they're doing.

 the "ridiculous counterexample" to what you are suggesting is that
 just because "rm -fr /*" does such a lot of damage, rm should have
 its "-r" option removed.  perhaps a better example would involve
 rsync, which even as far back as 1999 had already run out of
 lowercase _and_ uppercase letters to use as options... but i can't
 think of one because rsync is awesome :)

 l.

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