linux-kernel - Re: [PATCH 0/2] exec: allow core_pipe recursion check to look for a value of 1 rather than 0 (v2)

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: <20100129151024.GA19249@hmsreliant.think-freely.org>
Date:	Fri, 29 Jan 2010 10:10:24 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	linux-kernel@...r.kernel.org
Cc:	akpm@...ux-foundation.org, jmoskovc@...hat.com, mingo@...hat.com,
	drbd-dev@...ts.linbit.com, benh@...nel.crashing.org,
	t.sailer@...mni.ethz.ch, abelay@....edu, gregkh@...e.de,
	spock@...too.org, viro@...iv.linux.org.uk, neilb@...e.de,
	mfasheh@...e.com, menage@...gle.com,
	shemminger@...ux-foundation.org, takedakn@...data.co.jp,
	oleg@...hat.com
Subject: Re: [PATCH 0/2] exec: allow core_pipe recursion check to look for a
 value of 1 rather than 0 (v2)

Ok, version two of this patch.  I've cleaned up the comments, checkpatched,
rediffed to the latest -mm, etc.  More interestingly, I've taken Olegs changes
into account in this version of the patch.  By modifying Andi's work slightly,
I've introduced a new init fptr to the usermodehelper api, which lets a caller
customize the process that will be doing the helping.  In the case of the
do_coredump path its now used to create the read/write pipes.  This allows us to
remove the stdin specifics from the usermodehelper internals and factor our
call_usermodehelper_pipe entirely.  I've tested this myself using abrt on
Fedora, with good results

Summary:
	So, about 6 months ago, I made a set of changes to how the
core-dump-to-a-pipe feature in the kernel works.  We had reports of several
races, including some reports of apps bypassing our recursion check so that a
process that was forked as part of a core_pattern setup could infinitely crash
and refork until the system crashed.

	We fixes those by improving our recursion checks.  The new check
basically refuses to fork a process if its core limit is zero, which works well.

	Unfortunately, I've been getting grief from maintainer of user space
programs that are inserted as the forked process of core_pattern.  They contend
that in order for their programs (such as abrt and apport) to work, all the
running processes in a system must have their core limits set to a non-zero
value, to which I say 'yes'.  I did this by design, and think thats the right
way to do things.

	But I've been asked to ease this burden on user space enough times that
I thought I would take a look at it.  The first suggestion was to make the
recursion check fail on a non-zero 'special' number, like one.  That way the
core collector process could set its core size ulimit to 1, and enable the
kernel's recursion detection.  This isn't a bad idea on the surface, but I don't
like it since its opt-in, in that if a program like abrt or apport has a bug and
fails to set such a core limit, we're left with a recursively crashing system
again.

	So I've come up with this.  What I've done is modify the
call_usermodehelper api such that an extra parameter is added, a function
pointer which will be called by the user helper task, after it forks, but before
it exec's the required process.  This will give the caller the opportunity to
get a call back in the processes context, allowing it to do whatever it needs to
to the process in the kernel prior to exec-ing the user space code.  In the case
of do_coredump, this callback is ues to set the core ulimit of the helper
process to 1.  This elimnates the opt-in problem that I had above, as it allows
the ulimit for core sizes to be set to the value of 1, which is what the
recursion check looks for in do_coredump.

	This patch has been tested successfully by some of the Abrt maintainers
in fedora, with good results.  Patch applies to the latest -mm tree as of this
AM.

Neil

Signed-off-by: Neil Horman <nhorman@...driver.com>
Tested-by: Neil Horman <nhorman@...hat.com>
CC: Ingo Molnar <mingo@...hat.com>
CC: drbd-dev@...ts.linbit.com
CC: Benjamin Herrenschmidt <benh@...nel.crashing.org>
CC: Thomas Sailer <t.sailer@...mni.ethz.ch>
CC: Adam Belay <abelay@....edu>
CC: Greg Kroah-Hartman <gregkh@...e.de>
CC: Michal Januszewski <spock@...too.org>
CC: Al Viro <viro@...iv.linux.org.uk>
CC: Neil Brown <neilb@...e.de>
CC: Mark Fasheh <mfasheh@...e.com>
CC: Paul Menage <menage@...gle.com>
CC: Stephen Hemminger <shemminger@...ux-foundation.org>
CC: Kentaro Takeda <takedakn@...data.co.jp>
CC: Oleg Nesterov <oleg@...hat.com
--
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/