linux-kernel - Re: [PATCH v2] core_pattern: set core helpers root and namespace to crashing process

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:	Fri, 14 Dec 2012 15:10:30 -0800
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Neil Horman <nhorman@...driver.com>
Cc:	linux-kernel@...r.kernel.org,
	containers@...ts.linux-foundation.org,
	Alexander Viro <viro@...iv.linux.org.uk>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v2] core_pattern: set core helpers root and namespace to crashing process

Neil Horman <nhorman@...driver.com> writes:

> As its currently implemented, redirection of core dumps to a pipe reader should
> be executed such that the reader runs in the namespace of the crashing process,
> and it currently does not. This is the only sane way to deal with namespaces
> properly it seems to me, and this patch implements that functionality.

I actually rather strongly disagree.

While we have a global core dump pattern core dumps to a a pipe reader
should be executed such that the reader runs in the namespace of the
process that set the pattern.  We can easily restrict that to the
initial namespaces to make the implementation simpler.

If you want to play namespace games you can implement all of those in
user space once my tree merges for v3.8.

I am really not a fan of the trigger process being able to control the
environment of a privileged process.  It makes writing the privileged
process much trickier.

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