[lxc-devel] Device Namespaces

Michael J Coss michael.coss at alcatel-lucent.com
Thu Sep 26 17:17:54 UTC 2013


As I mentioned in another part of this thread, my use case is deploying 
"linux desktops" to users as containers.  The goal is to have the 
container run unmodified distros, and to be able to run arbitrary code.  
A tall order to be sure, and maybe not realistic, but I'm in research so 
its good to think big.

To that end, we would like the container to be manage as if it were a 
"real" system.  This includes udev.  I realize that udev no longer 
creates devices but uses devtmpfs, but the event notification needs to 
be seen for other parts to the system, and for the rules that udev 
actually does.  In particular, X uses uevents to detect keyboard, mice 
and display connections.

But when a new device is added, we need that information to go to only 
the appropriate container.  Currently, uevents are broadcasted to all 
listeners in all network namespaces.  I have a set of patches that 
restrict the initial broadcast to only the host namespace.  The second 
part is a user space deamon that applies policy and forwards the message 
to the container's udev.  But rather than have to run a modified udev, 
by allowing an interface for the host to inject a replay of the original 
message to the container's udev, we achieve at least part of our goal.

This still leave devtmpfs, and while I do believe that there are user 
space solutions, I think a virtualization of that is a better approach.  
The policy needs to be driven by the host, but the view of the synthetic 
filesystem should be managed by the kernel.

There are a number of other kernel filesystems that are equally 
problematic, sysfs, proc, debugfs, etc.  Is it really proposed that all 
of these be handled in userspace?. We can get some safety by disallows 
some mounts, and using readonly, but a unified policy would be nice.

My kernel patch is just to facility the communication to the container 
of the appropriate uevents, and the daemon uses libudev to collect, 
apply policy, and forward the appropriate events.  And I'm working on a 
solution for devtmpfs

---Michael J Coss




More information about the lxc-devel mailing list