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: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	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>
Subject: Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
Date: Mon, 19 May 2014 17:04:55 -0700	[thread overview]
Message-ID: <87mwedfh7c.fsf@x220.int.ebiederm.org> (raw)
In-Reply-To: <20140516201841.GC23902@ubuntu-hedt> (Seth Forshee's message of "Fri, 16 May 2014 15:18:41 -0500")

Seth Forshee <seth.forshee@canonical.com> writes:

> What I set out for was feature parity between loop devices in a secure
> container and loop devices on the host. Since some operations currently
> check for system-wide CAP_SYS_ADMIN, the only way I see to accomplish
> this is to push knowledge of the user namespace farther down into the
> driver stack so the check can instead be for CAP_SYS_ADMIN in the user
> namespace associated with the device.
>
> That said, I suspect our current use cases can get by without these
> capabilities. Really though I suspect this is just deferring the
> discussion rather than settling it, and what we'll end up with is little
> more than a fancy way for userspace to ask the kernel to run mknod on
> its behalf.

A fancy way to ask the kernel to run mknod on its behalf is what
/dev/pts is.

When I suggested this I did not mean you should forgo making changes to
allow partitions and the like.  What I itended is that you should find a
way to make this safe for users who don't have root capabilities.

Which possibly means that mount needs to learn how to keep a more
privileged user from using your new loop devices.

To get to the point where this is really and truly usable I expect to be
technically daunting.

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.

Only when the question is can this kernel functionality which is
otherwise safe confuse a preexisting setuid application do namespace
or container bits significantly come into play.

Eric