Serge Hallyn <serge.hal...@ubuntu.com> writes: >> But getting back to the question of policy, does it make sense that the >> way policy is implemented > > Policy is not implemented. > >> is that the all containers receive the events, >> and container configuration determines what uevents should/can be >> processed by that container. Or should it be handled elsewhere? > > As Stéphane has said, it should be handled by a devices namespace.
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 ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_mar _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
