From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: mhw@WittsEnd.com
Cc: 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 12:52:21 -0700 [thread overview]
Message-ID: <1400269941.2221.98.camel@dabdike.int.hansenpartnership.com> (raw)
In-Reply-To: <1400269360.3540.26.camel@canyon.ip6.wittsend.com>
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
next prev parent reply other threads:[~2014-05-16 19:52 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-05-14 21:34 [RFC PATCH 00/11] Add support for devtmpfs in user namespaces 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 ` James Bottomley [this message]
2014-05-16 20:04 ` [lxc-devel] Mount and other notifiers, was: " Michael H. Warfield
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=1400269941.2221.98.camel@dabdike.int.hansenpartnership.com \
--to=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=mhw@WittsEnd.com \
--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;
as well as URLs for NNTP newsgroup(s).