[lxc-devel] Dynamic devices

[Eric W. Biederman]

Michael J Coss <michael.coss at alcatel-lucent.com> writes:

> On 3/18/2013 11:45 PM, Eric W. Biederman wrote:
>> I will say what I have said elsewhere recently to ensure the idea
>> percolates. What can be implemented now without kernel support and
>> that is interesting is devtmpfs emulation. That is a tmpfs
>> filesystem inside the container to serve as /dev. A process outside
>> the container (with not particular privileges) that has acess to the
>> container's dev. The process would then wait for a uevent, and based
>> on some policy do roughly touch /containerpath/dev/name; mount
>> --bind /dev/name /containerpath/dev/name Or umount -l 
>> /containerpath/dev/name; unlink /containerpath/dev/name. The normal
>> udev policy would then have to allow the users in the container
>> access to those device nodes. I think that is simple and pretty
>> doable right now without much code. I suppose I stupid version could
>> even safely propogate all device nodes into a container that uses
>> user namespaces without danger. Which implies an even simpler
>> solution for user namespace based containers. Except for special
>> cases it is possible and safe to just share the same /dev filesystem
>> inside and outside of the container. That means /dev/ptmx needs to
>> link to /dev/pts/ptmx and that you can't pretend to have /dev/ttyN
>> inside the contianer but I can't think of any other downsides.  Eric 
> So here's the scenario that I'd like to find a solution for:
>
>  I have two "identical" USB devices, A and B, and  I plug them into
> the host system, in some arbitrary order.  What I would like to be
> able to do is assign A to container 1, and B to container
> 2. Irrelevant of whether A or B is inserted first into the system.
> I'd like the two devices to be "staged" into the host, and then
> following some administrative action A is bound to container 1, and B
> is bound to container 2.  If the devices are USB serial ports, one
> will become ttyUSB0, and the other will be ttyUSB1.  Which device gets
> assigned to which name, barring some tagging is insertion order
> dependent.
>
> There is external knowledge that must be provided to make the
> association, namely that the back end of those serial ports are
> connected to different physical piece of hardware, independent of
> which USB slot that the cable is plugged into.
>
> I was thinking that a hotplug script running on the host could do
> something like you describe.  I would have to disable the propagation
> of the uevent to the container, or simply remove the capability of
> doing mknod from the container completely.


> I'm still trying to figure out why the udev running in my Gentoo
> container doesn't create devices even though it has the capability to
> do so.

A new enough udev depends exclusively on devtmpfs for creating devices.
Aka udev has abdicated it's job and no longer implements anything except
chmod and symlink creation.  If your Gentoo is recent enough that may
explain it.

If your Gentoo in your container won't create devices then I don't think
you have much to worry about on that score.

If you can write the udev rules so outside of your container you get
stable names for two "identical" USB devices you should also be able
to come up with a script that pushes those devices into your containers.

In your script that pushes a device into your container you can either
do setns and mknod, have the filesystem shared, or setup mount
propagation.

Eric