linux-kernel - Re: [Patch 2/8] ipc/mqueue: switch back to using non-max values on create

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]

Message-Id: <20120417151729.e255188c.akpm@linux-foundation.org>
Date:	Tue, 17 Apr 2012 15:17:29 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Doug Ledford <dledford@...hat.com>
Cc:	linux-kernel@...r.kernel.org, kosaki.motohiro@...il.com
Subject: Re: [Patch 2/8] ipc/mqueue: switch back to using non-max values on
 create

On Tue, 17 Apr 2012 11:46:19 -0400
Doug Ledford <dledford@...hat.com> wrote:

> Commit b231cca4381ee15ec99afbfb244fbc0324869927 changed
> how we create a queue that does not include an attr
> struct passed to open so that it creates the queue
> with whatever the maximum values are.  However, if the
> admin has set the maximums to allow flexibility in
> creating a queue (aka, both a large size and large queue
> are allowed, but combined they create a queue too large
> for the RLIMIT_MSGQUEUE of the user), then attempts to
> create a queue without an attr struct will fail.  Switch
> back to using acceptable defaults regardless of what
> the maximums are.
> 
> Note: so far, we only know of a few applications that rely
> on this behavior (specifically, set the maximums in /proc,
> then run the application which calls mq_open() without
> passing in an attr struct, and the application expects the
> newly created message queue to have the maximum sizes that
> were set in /proc used on the mq_open() call, and all of
> those applications that we know of are actually part of
> regression test suites that were coded to do something
> like this:
> 
> for size in 4096 65536 $((1024 * 1024)) $((16 * 1024 * 1024)); do
> 	echo $size > /proc/sys/fs/mqueue/msgsize_max
> 	mq_open || echo "Error opening mq with size $size"
> done
> 
> These test suites that depend on any behavior like this are
> broken.  The concept that programs should rely upon the
> system wide maximum in order to get their desired results
> instead of simply using a attr struct to specify what they
> want is fundamentally unfriendly programming practice for
> any multi-tasking OS.
> 
> Fixing this will break those few apps that we know of (and
> those app authors recognize the brokenness of their code
> and the need to fix it).  However, a future patch will allow
> a workaround in the form of new knobs for the default
> msg queue creation parameters for any software out there that
> we don't already know about that might rely on this behavior
> at the moment.

Here the "future patch" is "mqueue: separate mqueue default value from
maximum value v2" in this series, yes?

So people who have applications which are broken by this patch will
need to manually set /proc/sys/fs/mqueue/msg_default and/or
/proc/sys/fs/mqueue/msgsize_default to get those apps working again?

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