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:	Thu, 13 Dec 2012 21:49:39 -0500
From:	Neil Horman <nhorman@...driver.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Serge Hallyn <serge.hallyn@...onical.com>,
	linux-kernel@...r.kernel.org,
	Daniel Berrange <berrange@...hat.com>,
	Alexander Viro <viro@...iv.linux.org.uk>,
	containers@...ts.linux-foundation.org
Subject: Re: [PATCH] core_pattern: set core helpers root and namespace to
 crashing process

On Thu, Dec 13, 2012 at 02:25:34PM -0800, Andrew Morton wrote:
> On Thu, 13 Dec 2012 13:12:20 -0500
> Neil Horman <nhorman@...driver.com> wrote:
> 
> > On Thu, Dec 13, 2012 at 06:20:48AM -0600, Serge Hallyn wrote:
> > > Quoting Neil Horman (nhorman@...driver.com):
> > > > Theres one problem I currently see with it, and that is that I'm not sure we can
> > > > change the current behavior of how the root fs is set for the pipe reader, lest
> > > > we break some user space expectations. As such, I've added a sysctl in this
> > > > patch to allow administrators to globally select if a core reader specified via
> > > > /proc/sys/kernel/core_pattern should use the global rootfs, or the (possibly)
> > > > chrooted fs of the crashing process.
> > > 
> > > Practical question:  How is the admin to make an educated decision on
> > > how to set the sysctl?
> 
> By reading the documentation which Neil didn't include?
> 
Yeah, that was stupid of me, I'll respin this with docs.

> > My thought was that the admin typically wouldn't touch this at all.  I really
> > added it as a backwards compatibility option only.  Setting the user space
> > helper task to the root of the crashing parent has the possibility of breaking
> > existing installs because the core_pattern helper might be expecting global file
> > system access.  Moving forward, my expectation would be that core_pattern
> > helpers would be written with the default setting in mind, and we could
> > eventually deprecate the control entirely.
> > 
> > If you have a better mechanism in mind however (or if you think that removing
> > the control is a resaonable approach), I'm certainly open to that.
> 
> Yeah, this is a tiresome patch but I can't think of a better way.
> 
> Except, perhaps, adding a new token to the core_pattern which says
> "switch namespaces"?
>
I like that idea, perhaps '||' instead of '|' as the leading token can indicate
"use the namespace root" vs. "use the global root".  Thoughts?

> Is there any propect that the core_pattern itself will later become a
> per-namespace containerised thing?  I guess that if the per-container
> core_pattern has been configured, we can implicitly do the namespace
> switch as well.
Yes, that makes sense.  Unfortunately, I don't see proc containerization
happening any time soon.  I suppose if we do the above tokenization, that can be
used despite any future containerization that takes place.

I'll respin the patch with documentation, and replace the extra sysctl with the
above tokenization in the AM.

Best
Neil
 
> 
> 
--
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