linux-kernel - Re: [PATCH 11/11] blkcg: implement per-blkg request allocation

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]

Date:	Fri, 27 Apr 2012 09:20:12 -0700
From:	Tejun Heo <tj@...nel.org>
To:	Vivek Goyal <vgoyal@...hat.com>
Cc:	Jeff Moyer <jmoyer@...hat.com>, axboe@...nel.dk,
	ctalbott@...gle.com, rni@...gle.com, linux-kernel@...r.kernel.org,
	cgroups@...r.kernel.org, containers@...ts.linux-foundation.org,
	fengguang.wu@...el.com, hughd@...gle.com, akpm@...ux-foundation.org
Subject: Re: [PATCH 11/11] blkcg: implement per-blkg request allocation

Hello,

On Fri, Apr 27, 2012 at 11:56:12AM -0400, Vivek Goyal wrote:
> > I find allowing unpriv users creating cgroups dumb.  cgroup consumes
> > kernel memory.  Sans using kmemcg, what prevents them from creating
> > gazillion cgroups and consuming all memories?  The idea of allowing
> > cgroups to !priv users is just broken from the get go.
> 
> Well creating a task consumes memory too but we allow unpriv users to
> create tasks. :-)

We have ulimit.

> May be a system wide cgroup limit will make sense?

IMHO, this was one of the larger mistakes cgroup has made.  There are
two ways when building interface for admin stuff like this, you can
either implement and expose the core functionality and let userland
deal with distribution or build things such that the kernel can fully
virtualize and distribute the control to each process.  Both
approaches have their pros and cons but I generally think it's better
to go for the latter for new and extra stuff like cgroup as it is much
simpler and tends to more flexible and adapts better as use cases
develop.

The problem with cgroup is that it's neither the former or the latter.
It's caught somewhere in the middle with its pants down where it does
half-assed job of providing an interface which looks like it could be
made to be directly accessible from !priv processes while not really
being able to handle such usage.

I mean, just think about the case you just raised.  Forget about
memory usage.  What about weights?  If you allow a random user to
create arbitrary number of blkcg groups, [s]he gets 500 extra weight
with each blkcg!  Yeah!

If we support full hierarchy on all controllers, exposing cgroups
directly to !priv users may start to make more sense but I'd much
prefer having resource policy controlled and administered centrally in
userland.  It's a job much better suited for userland.  If such
mechanism would require certain features, sure we can accomodate that
but I think trying to allow !priv users directly to cgroup is stupid
especially at this point, so let's just drop it.

Thanks.

-- 
tejun
--
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/