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

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: <1400269941.2221.98.camel@dabdike.int.hansenpartnership.com>
Date:	Fri, 16 May 2014 12:52:21 -0700
From:	James Bottomley <James.Bottomley@...senPartnership.com>
To:	mhw@...tsEnd.com
Cc:	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 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


--
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/