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 | m...@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!
signature.asc
Description: This is a digitally signed message part
