[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4F8ECED3.5070909@redhat.com>
Date: Wed, 18 Apr 2012 10:25:23 -0400
From: Doug Ledford <dledford@...hat.com>
To: "Serge E. Hallyn" <serge@...lyn.com>
CC: linux-kernel@...r.kernel.org, akpm@...ux-foundation.org,
kosaki.motohiro@...il.com,
KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
Amerigo Wang <amwang@...hat.com>,
"Serge E. Hallyn" <serue@...ibm.com>, Jiri Slaby <jslaby@...e.cz>
Subject: Re: [Patch 5/8] mqueue: revert bump up DFLT_*MAX
On 4/17/2012 11:22 PM, Serge E. Hallyn wrote:
> Quoting Doug Ledford (dledford@...hat.com):
>> From: KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>
>>
>> Mqueue limitation is slightly naieve parameter likes other ipcs
>> because unprivileged user can consume kernel memory by using ipcs.
>>
>> Thus, too aggressive raise bring us security issue. Example,
>> current setting allow evil unprivileged user use 256GB (= 256
>> * 1024 * 1024*1024) and it's enough large to system will belome
>> unresponsive. Don't do that.
>>
>> Instead, every admin should adjust the knobs for their own systems.
>
> Would you be terribly averse to having a higher limit in init_ipc_ns,
> and the lower values by default in all child namespaces?
>
> Sorry it sounds from the intro like you've already had quite a bit of
> discussion on this...
>
> Of course I realize the values can just be raised by distro boot
> scripts...
The default maximums this patch put into place were in fact in place
from 2008 until my earlier patch in this same series, so in that regard
this is merely restoring an already established default maximum. It
*could* be raised, yes, but as Motohiro pointed out, this is pinned
memory that any user can allocate, so the smaller the default amount the
better. The sysadmin can make changes as they see fit.
--
Doug Ledford <dledford@...hat.com>
GPG KeyID: 0E572FDD
http://people.redhat.com/dledford
Infiniband specific RPMs available at
http://people.redhat.com/dledford/Infiniband
Download attachment "signature.asc" of type "application/pgp-signature" (899 bytes)
Powered by blists - more mailing lists