Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

2014-05-17 Thread James Bottomley
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.

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).

James


___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel


Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

2014-05-16 Thread Michael H. Warfield
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 |  m...@wittsend.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!



signature.asc
Description: This is a digitally signed message part
___
lxc-devel mailing list
lxc-devel@lists.linuxcontainers.org
http://lists.linuxcontainers.org/listinfo/lxc-devel