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: <1400270662.3540.32.camel@canyon.ip6.wittsend.com>
Date:	Fri, 16 May 2014 16:04:22 -0400
From:	"Michael H. Warfield" <mhw@...tsEnd.com>
To:	James Bottomley <James.Bottomley@...senPartnership.com>
Cc:	"Michael H.Warfield" <mhw@...tsEnd.com>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Serge Hallyn <serge.hallyn@...ntu.com>,
	linux-kernel@...r.kernel.org, Jens Axboe <axboe@...nel.dk>,
	Arnd Bergmann <arnd@...db.de>,
	Eric Biederman <ebiederm@...ssion.com>,
	Serge Hallyn <serge.hallyn@...onical.com>,
	lxc-devel@...ts.linuxcontainers.org,
	Pavel Emelianov <xemul@...allels.com>
Subject: Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11]
 Add support for devtmpfs in user namespaces

On Fri, 2014-05-16 at 12:52 -0700, James Bottomley wrote:
> On Fri, 2014-05-16 at 15:42 -0400, Michael H. Warfield wrote:
> > > As an aside (probably requiring a new thread) we were wondering about
> > > some type of notifier on the mount call that we could vector into the
> > > host to perform the action.  The main issue for us is mount of procfs,
> > > which really needs to be a bind mount in a container.  All of this led
> > > me to speculate that we could use some type of syscall notifier
> > > mechanism to manage capabilities in the host and even intercept and
> > > complete the syscall action within the host rather than having to keep
> > > evolving more an more complex kernel drivers to do this.
> > 
> > Interesting.  That could be very useful.  That might even help with the
> > loop device case where the mounts have to go through loop devices for
> > things like file system images and builds.  Very interesting...

> Right, it might even make the loop case go away because now we can
> present a dummy device in the container and when the host sees and
> attempted mount on this, it just projects a bind mount into the
> container and says I've *wink* mounted your "device" for you.

Nice.  That idea has prospects.  I like the concept.

> This idea is extremely rough, it came from a conversation I had with
> Pavel (cc'd) just before OpenStack about how we might go about
> eliminating our OpenVZ interception of the mount system call which
> currently does all of this in kernel, so we have no code and no proof
> that it's actually feasible (yet).

K.  I look forward to hearing more.

I switched from OpenVZ years ago to LXC because OpenVZ was falling too
far behind in kernel support and patches for the leading edge kernels.
At the time, I was working on the MD5 signature code for the Quagga
routing suite for BGP and couldn't maintain my hosts with OpenVZ and
maintain my BGP connections (I have a public ASN and peer on both IPv4
and IPv6) with MD5 signatures at the same time.  At the time LXC had
just matured enough to serve my needs.  That's interesting to note that
OpenVZ did this by intercepting the mount call.  Very interesting...

> James

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw@...tsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!


Download attachment "signature.asc" of type "application/pgp-signature" (483 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ