linux-kernel - Re: [resend][PATCH 1/3] mqueue: revert bump up DFLT

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:	Wed, 14 Mar 2012 17:28:33 -0400
From:	Doug Ledford <dledford@...hat.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	KOSAKI Motohiro <kosaki.motohiro@...il.com>,
	linux-kernel@...r.kernel.org,
	KOSAKI Motohiro <kosaki.motohiro@...fujitsu.com>,
	Amerigo Wang <amwang@...hat.com>,
	"Serge E. Hallyn" <serue@...ibm.com>, Jiri Slaby <jslaby@...e.cz>,
	"\"Eric W. Biederman\" (commit_signer:2/9=22%)" 
	<ebiederm@...ssion.com>,
	"Joe Korty (commit_signer:2/9=22%)" <joe.korty@...r.com>,
	"David Howells (commit_signer:2/9=22%)" <dhowells@...hat.com>
Subject: Re: [resend][PATCH 1/3] mqueue: revert bump up DFLT_*MAX

On 12/18/2011 01:38 PM, Andrew Morton wrote:
> On Sun, 18 Dec 2011 13:29:56 -0500 KOSAKI Motohiro <kosaki.motohiro@...il.com> wrote:
> 
>> (12/9/11 5:35 PM), kosaki.motohiro@...il.com wrote:
>>> 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.
>>>
>>> Signed-off-by: KOSAKI Motohiro<kosaki.motohiro@...fujitsu.com>
>>> Acked-by: Doug Ledford<dledford@...hat.com>
>>> Acked-by: Joe Korty<joe.korty@...r.com>
>>> Cc: Amerigo Wang<amwang@...hat.com>
>>> Cc: Serge E. Hallyn<serue@...ibm.com>
>>> Cc: Jiri Slaby<jslaby@...e.cz>
>>
>> Andrew, can you please pick up this series into your tree? because your
>> tree have related Doug mqueue patch series.
> 
> Soon.  I need to go back and read the email trail regarding Doug's patches.

This has obviously fallen through the cracks.  Can we please see if we
can get this put to bed.

Andrew, long and short of the story on this entire patch set is:

A) Current Linus kernel is broken in regards to customer needs, maximums
are too low.
B) My patch set upped maximums and also upped the default maximums on
the system, but inadvertently also upped the default mqueue size the
original patch that my entire patch set is more or less reverting tied
maximums and defaults together.  This broke some apps that didn't pass
an attr struct to open as it caused a default sized mqueue to exceed a
non-root RLIMIT for message queue bytes.
C) My next patches brought defaults back down by decoupling defaults
from maximums.  This then broke some apps again that wanted to be able
to fiddle with the maximum settings in /proc and have that modify the
default value for an app that didn't pass an attr struct (fortunately,
all of these apps appear to be nothing more than regression test suites
at the moment where the people writing the suite used a combination of
setting the maximum size in proc, then running a test program that
created a default queue and checking it, then re-running with different
sizes in /proc, etc).
D) Motohiro and I argued for some time over this behavior until we both
agreed that apps can not be written to rely upon the maximum setting of
the system wide mqueue limits as their default queue size as this is
fundamentally unfriendly behavior to any multi-application OS (the
situation of two apps both needing specific, different queue sizes, and
both expecting to get them by default by twiddling values in /proc is
simply not supportable).  In the end, we agreed that the best approach
to solve the problem was to leave the defaults decoupled from the
maximums, but add a default knob in /proc so that if there are any apps
out there that have been coded to expect this behavior, then there is a
workaround path for them until they get coded to use an attr struct on
open instead of relying on values twiddled in /proc.  This is what
Motohiro's patch set does as well as a few other cleanups.

Hopefully that clears things up, and given the unsupportability of the
current design in Linus' kernel (changing maximums changes defaults for
all apps and encourages poor programming choices) we can move this
forward please.

-- 
Doug Ledford <dledford@...hat.com>
              GPG KeyID: 0E572FDD
	      http://people.redhat.com/dledford

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