linux-kernel - Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new cgroup namespaces

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20160520173353.GB26350@odin.tremily.us>
Date:	Fri, 20 May 2016 10:33:53 -0700
From:	"W. Trevor King" <wking@...mily.us>
To:	Tejun Heo <tj@...nel.org>
Cc:	James Bottomley <James.Bottomley@...senPartnership.com>,
	Aleksa Sarai <asarai@...e.de>, Li Zefan <lizefan@...wei.com>,
	Johannes Weiner <hannes@...xchg.org>,
	Aleksa Sarai <cyphar@...har.com>, cgroups@...r.kernel.org,
	linux-kernel@...r.kernel.org, dev@...ncontainers.org
Subject: Re: [PATCH v4 0/2] cgroup: allow management of subtrees by new
 cgroup namespaces

I'm just chipping in from the peanut gallery, so sorry if this misses
some earlier discussion.

On Fri, May 20, 2016 at 12:53:26PM -0400, Tejun Heo wrote:
> Why does an unpriv NS need to have cgroup delegated to it without
> cooperation from cgroup manager?  If for resource control, I'm
> pretty sure we don't want to allow that without explicit cooperation
> from the enclosing scope.

A useful analogy is renice(1), which allows users to manage the way
their allocated resources are distributed among their processes.  A
system where a sysadmin has to explicitly grant users permission to
use renice seems overly restrictive, as does a system where a sysadmin
has to explicitly grant users permission to use cgroups to manage
their resources.  At that level, the only different is probably that
adjusting niceness doesn't consume additional system resources, while
creating a new cgroup does, and sysadmins might want to protect
themselves from having users create zillions of cgroups.

On the other hand, sysadmins who do want to grant this power can
automatically put users in their own cgroup with adjusted POSIX
permissions at login time (e.g. “Hi Alice, here's your own cgroup to
manage as you see fit.  Hi Bob, …”).  But having a way to say “I'm
fine with users creating their own cgroup namespaces and sub-cgroups”
is easier.  And making it opt-out (“I'm *not* fine with users creating
their own…”) is even easier, and the choice between opt-in and opt-out
probably depends on how expensive cgroups are.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)