From: "Michael H. Warfield" <mhw@WittsEnd.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
Cc: "Michael H.Warfield" <mhw@WittsEnd.com>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
Serge Hallyn <serge.hallyn@ubuntu.com>,
linux-kernel@vger.kernel.org, Jens Axboe <axboe@kernel.dk>,
Arnd Bergmann <arnd@arndb.de>,
Eric Biederman <ebiederm@xmission.com>,
Serge Hallyn <serge.hallyn@canonical.com>,
lxc-devel@lists.linuxcontainers.org,
Pavel Emelianov <xemul@parallels.com>
Subject: Re: [lxc-devel] Mount and other notifiers, was: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Date: Fri, 16 May 2014 16:04:22 -0400 [thread overview]
Message-ID: <1400270662.3540.32.camel@canyon.ip6.wittsend.com> (raw)
In-Reply-To: <1400269941.2221.98.camel@dabdike.int.hansenpartnership.com>
[-- Attachment #1: Type: text/plain, Size: 2544 bytes --]
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@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!
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]
next prev parent reply other threads:[~2014-05-16 20:07 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 21:34 Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 01/11] driver core: Assign owning user namespace to devices Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 02/11] driver core: Add device_create_global() Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 03/11] tmpfs: Add sub-filesystem data pointer to shmem_sb_info Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 04/11] ramfs: Add sub-filesystem data pointer to ram_fs_info Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 05/11] devtmpfs: Add support for mounting in user namespaces Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 06/11] drivers/char/mem.c: Make null/zero/full/random/urandom available to " Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 07/11] block: Make partitions inherit namespace from whole disk device Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 08/11] block: Allow blkdev ioctls within user namespaces Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 09/11] misc: Make loop-control available to all " Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 10/11] loop: Assign devices to current_user_ns() Seth Forshee
2014-05-14 21:34 ` [RFC PATCH 11/11] loop: Allow priveleged operations for root in the namespace which owns a device Seth Forshee
2014-05-23 5:48 ` Marian Marinov
2014-05-26 9:16 ` Seth Forshee
2014-05-26 15:32 ` [lxc-devel] " Michael H. Warfield
2014-05-26 15:45 ` Seth Forshee
2014-05-27 1:36 ` Serge E. Hallyn
2014-05-27 2:39 ` Michael H. Warfield
2014-05-27 7:16 ` Seth Forshee
2014-05-27 13:16 ` Serge Hallyn
2014-05-15 1:32 ` [RFC PATCH 00/11] Add support for devtmpfs in user namespaces Greg Kroah-Hartman
2014-05-15 2:17 ` [lxc-devel] " Michael H. Warfield
2014-05-15 3:15 ` Seth Forshee
2014-05-15 4:00 ` Greg Kroah-Hartman
2014-05-15 13:42 ` Michael H. Warfield
2014-05-15 14:08 ` Greg Kroah-Hartman
2014-05-15 17:42 ` Serge Hallyn
2014-05-15 18:12 ` Seth Forshee
2014-05-15 22:15 ` Greg Kroah-Hartman
2014-05-16 1:42 ` Michael H. Warfield
2014-05-16 7:56 ` Richard Weinberger
2014-05-16 19:20 ` James Bottomley
2014-05-16 19:42 ` Michael H. Warfield
2014-05-16 19:52 ` [lxc-devel] Mount and other notifiers, was: " James Bottomley
2014-05-16 20:04 ` Michael H. Warfield [this message]
2014-05-16 1:49 ` [lxc-devel] " Serge Hallyn
2014-05-16 4:35 ` Greg Kroah-Hartman
2014-05-16 14:06 ` Seth Forshee
2014-05-16 15:28 ` Michael H. Warfield
2014-05-16 15:43 ` Seth Forshee
2014-05-16 18:57 ` Greg Kroah-Hartman
2014-05-16 19:28 ` James Bottomley
2014-05-16 20:18 ` Seth Forshee
2014-05-20 0:04 ` Eric W. Biederman
2014-05-20 1:14 ` Michael H. Warfield
2014-05-20 14:18 ` Serge Hallyn
2014-05-20 14:21 ` Seth Forshee
2014-05-21 22:00 ` Eric W. Biederman
2014-05-21 22:33 ` Serge Hallyn
2014-05-23 22:23 ` Eric W. Biederman
2014-05-28 9:26 ` Seth Forshee
2014-05-28 13:12 ` Serge E. Hallyn
2014-05-28 20:33 ` Eric W. Biederman
2014-05-18 2:42 ` Serge E. Hallyn
2014-05-17 4:31 ` Eric W. Biederman
2014-05-17 16:01 ` Seth Forshee
2014-05-18 2:44 ` Serge E. Hallyn
2014-05-19 13:27 ` Seth Forshee
2014-05-20 14:15 ` Serge Hallyn
2014-05-20 14:26 ` Serge Hallyn
2014-05-17 12:57 ` Michael H. Warfield
2014-05-15 18:25 ` Richard Weinberger
2014-05-15 19:50 ` Serge Hallyn
2014-05-15 20:13 ` Richard Weinberger
2014-05-15 20:26 ` Serge E. Hallyn
2014-05-15 20:33 ` Richard Weinberger
2014-05-19 20:22 ` Andy Lutomirski
2014-05-20 14:19 ` Serge Hallyn
2014-05-23 8:20 ` Marian Marinov
2014-05-23 13:16 ` James Bottomley
2014-05-23 16:39 ` Andy Lutomirski
2014-05-24 22:25 ` Serge Hallyn
2014-05-25 8:12 ` James Bottomley
2014-05-25 22:24 ` Serge E. Hallyn
2014-05-28 7:02 ` James Bottomley
2014-05-28 13:49 ` Serge Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1400270662.3540.32.camel@canyon.ip6.wittsend.com \
--to=mhw@wittsend.com \
--cc=James.Bottomley@HansenPartnership.com \
--cc=arnd@arndb.de \
--cc=axboe@kernel.dk \
--cc=ebiederm@xmission.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=lxc-devel@lists.linuxcontainers.org \
--cc=serge.hallyn@canonical.com \
--cc=serge.hallyn@ubuntu.com \
--cc=xemul@parallels.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®