[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140515013245.GA1764@kroah.com>
Date: Wed, 14 May 2014 18:32:45 -0700
From: Greg Kroah-Hartman <gregkh@...uxfoundation.org>
To: Seth Forshee <seth.forshee@...onical.com>
Cc: 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
Subject: Re: [RFC PATCH 00/11] Add support for devtmpfs in user namespaces
On Wed, May 14, 2014 at 04:34:48PM -0500, Seth Forshee wrote:
> Unpriveleged containers cannot run mknod, making it difficult to support
> devices which appear at runtime.
Wait.
Why would you even want a container to see a "new" device? That's the
whole point, your container should see a "clean" system, not the "this
USB device was just plugged in" system. Otherwise, how are you going to
even tell that container a new device showed up? Are you now going to
add udev support in containers? Hah, no.
> Using devtmpfs is one possible
> solution, and it would have the added benefit of making container setup
> simpler. But simply letting containers mount devtmpfs isn't sufficient
> since the container may need to see a different, more limited set of
> devices, and because different environments making modifications to
> the filesystem could lead to conflicts.
>
> This series solves these problems by assigning devices to user
> namespaces. Each device has an "owner" namespace which specifies which
> devtmpfs mount the device should appear in as well allowing priveleged
> operations on the device from that namespace. This defaults to
> init_user_ns. There's also an ns_global flag to indicate a device should
> appear in all devtmpfs mounts.
I'd strongly argue that this isn't even a "problem" at all. And, as I
said at the Plumbers conference last year, adding namespaces to devices
isn't going to happen, sorry. Please don't continue down this path.
greg k-h
--
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/
Powered by blists - more mailing lists