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: <20070726214633.GA11008@hmsreliant.homelinux.net>
Date:	Thu, 26 Jul 2007 17:46:33 -0400
From:	Neil Horman <nhorman@...driver.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	linux-kernel@...r.kernel.org, wwoods@...hat.com
Subject: Re: [PATCH] core_pattern: Add ability for core_pattern to parse arguments when pattern is a pipe

On Thu, Jul 26, 2007 at 01:35:36PM -0700, Andrew Morton wrote:
> On Thu, 26 Jul 2007 16:20:18 -0400 Neil Horman <nhorman@...driver.com> wrote:
> 
> > If you'd like to back them all out, I have them
> > all in a git tree here, and I can repost (say early next week when I finish
> > local testing) as a patch sequence, with all my screw-ups properly fixed,
> > and with an appropriate changelog describing the whole sequence.
> 
> hm, I have six fixes here against
> allow-individual-core-dump-methods-to-be-unlimited-when-sending-to-a-pipe.patch
> and I always worry that some might get lost.
> 
> How many more patches have you after this one?

I think the best organization that I could give you would leave me with one
patch remaining, for a total of three that you would have to carry:

Patch 1) Removing the RLIMIT_CORE restriction on core_dumps in do_coredump and
the core_dump methods from fs/binfmt_*.c

Patch 2) Add the ability to parse arguments out of
/proc/sys/kernel/core_pattern, along with the ability to specify the origional
RLIMIT_CORE size as an option.

Patch 3) fix up some pre-existing bugs that I found while doing the other work.
Specifically I found that call_usermodehelper_pipe waits for the usermodehelper
to exit.  Since we are redirecting stdin for the helper to a pipe, any reader of
the pipe will cause a deadlock in the do_coredump path.  I want to fix up that
and a few simmilar bugs.

You have the first two as you know, and I plan to be done with the third on
friday or monday.  Just let me know if you would like me to repost the first two
with the third as a sequence set.

As far as the changelog for these three (or six, if you want to count the
interviening fixes separately), you can use this:

For some time now /proc/sys/core_pattern has allowed for the specification that
the output desitination of a core dump be a pipe to a user space process, rather
than a file system location.  This enables a class of applications that allows
for intellegent handling of application crashes.  While the pipe core_pattern
infrastrucutre is beneficial, it is lacking in certain points.  Specifically it
is unable to dump cores if a users core dump ulimit is too low, despite the fact
that no data need be written to a filesystem.  It is also lacking in the sense
that while an application can be specified as the reader end of the pipe,
arguments cannot be currently passed to this application.  This set of patches
seeks to improve this infrastructure by:

1) Ignoring RLIMIT_CORE restrictions when the core destination is a pipe,
relying instead on user space security to prevent oversubscription of resources

2) Allowing arguments to be specified and passed to applications specified in
core_pattern

3) Fixing a few pre-existing bugs discovered during the aforementioned two
development points.


Thanks and Regards
Neil

P.S. Will, please send me email addresses for relevant interested parties from
ubuntu, and I'll happily copy them on these patches.


-- 
/***************************************************
 *Neil Horman
 *Software Engineer
 *Red Hat, Inc.
 *nhorman@...driver.com
 *gpg keyid: 1024D / 0x92A74FA1
 *http://pgp.mit.edu
 ***************************************************/
-
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ