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

["Michael H. Warfield" <mhw@WittsEnd.com>]

[-- Attachment #1: Type: text/plain, Size: 3184 bytes --]

On Wed, 2014-05-14 at 18:32 -0700, Greg Kroah-Hartman wrote:
> 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.

Oooo...  I can answer that...  Tell me if you've heard this one
before...  (You have back in NOLA last summer)...

I use a USB sharing device that controls a multiport USB serial device
controlling serial consoles to 16 servers and shared between 4
controlling servers.  The sharing control port (a USB HID device) should
be shared between designated containers so that any designated container
owner can "request" a console to one of the other servers (yeah, I know
there can be contention but that's the way the cookie crumbles - most of
the time it's on the master host).  Once they get the sharing device's
attention, they "lose" that HID control device (it disappears from /dev
entirely) and they gain only their designated USBtty{n} device for their
console.  Dynamic devices at their finest.

I worked out a way of dealing with it using udev rules in the host and
shifting devices using subdirectories in /dev.  I got the infrastructure
implemented but didn't finish the specific udev rules.

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

I was just mentioning that to Serge just a week or so ago reminding him
of what you told all of us face to face back then.  We were having a
discussion over loop devices into containers and this topic came up.

> greg k-h

Regards,
Mike
-- 
Michael H. Warfield (AI4NB) | (770) 978-7061 |  mhw@WittsEnd.com
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]