Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

From: ebiederm@xmission.com (Eric W. Biederman)
To: Seth Forshee <seth.forshee@canonical.com>
Cc: Serge Hallyn <serge.hallyn@ubuntu.com>,
	Jens Axboe <axboe@kernel.dk>,
	Serge Hallyn <serge.hallyn@canonical.com>,
	Arnd Bergmann <arnd@arndb.de>,
	linux-kernel@vger.kernel.org,
	LXC development mailing-list 
	<lxc-devel@lists.linuxcontainers.org>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Date: Wed, 21 May 2014 15:00:33 -0700	[thread overview]
Message-ID: <87y4xubxmm.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140520142103.GC137220@ubuntu-hedt> (Seth Forshee's message of "Tue, 20 May 2014 09:21:03 -0500")

>> Ultimately the technical challenge is how do we create a block device
>> that is safe for a user who does not have any capabilities to use, and
>> what can we do with that block device to make it useful.
>
> Yes, and I'd like to get started solving those challenges. But I also
> don't think we can address these two points (support partition blkdevs,
> help prevent more priveleged users from using a namespace's loop
> devices) sufficiently while having an implementation completely
> contained within the loop driver as Greg is requesting.

My key take away from the conversation is that we should reduce the
scope of what is being done to something that makes sense and the
propblems are immediately visible.

Part of me would like to suggest that fuse and it's ability to imitate
device nodes might be a more appropriate solution, to something that
just needs block device access and nothing else.

For purposes of discussion let's call it unprivloopfs.  That can reuse
code from the loop device or not as appropriate.  Not supporting
paritioning I think is a very reasonable first step until it is shown
that we can make good use of partitioning support, and there are not
better ways of solving the problem.

I expect the most productive thing to talk about is what is your
immediate goal?  Mounting a filesystem?  Building an iso?

We have a long history with the namespace support of punting on issues
and not solving them until a long term maintainable solution becomes
clear.  Let's do what we can to make the problem and the solution clear.

Eric