On Tue, 2013-10-01 at 15:46 -0500, Serge Hallyn wrote: > Quoting Eric W. Biederman (ebiederm-aS9lmoZGLiVWk0Htik3J/w@public.gmane.org): > > "Serge E. Hallyn" writes: > > > > > Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org): > > >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen wrote: > > >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman > > >> > wrote: > > >> > > > >> >>> - We can relay a call of /sbin/hotplug from outside of a container > > >> >>> to inside of a container based on policy. > > >> >>> (But no one uses /sbin/hotplug anymore). > > >> >> > > >> >> That's right, they should be listening to libudev events, so why can't > > >> >> your daemon shuffle them off to the proper container, all in userspace? > > >> > > > >> > Which reminds me, one potential reason being.. > > >> > http://lists.linuxfoundation.org/pipermail/containers/2013-May/032591.html > > >> > > > >> > > >> Can't the daemon live outside the container and shuffle stuff in? > > > > > > That's exactly what Michael Warfield is suggesting, fwiw. > > > > Michael Warfields example of dynamically assigning serial ports to > > containers is a pretty good test case. Serial ports are extremely well > > known kernel objects who evolution effectively stopped long ago. When > > we need it we have ptys to virtual serial ports when we need it, but in > > general unprivileged users are safe to directly use a serial port > > device. > > > > Glossing over the details. The general problem is some policy exists > > outside of the container that deciedes if an when a container gets a > > serial port and stuffs it in. > > > > The expectation is that system containers will then run the udev > > rules and send the libuevent event. > I thought the suggestion was that udev on the host would be given > container-specific rules, saying "plop this device into /dev/container1/" > (with /dev/container1 being bind-mounted to $container1_rootfs/dev). I think that the "given container-specific rules, saying..." thing was on my chart of options as the one with the big cloudy shaped object in the lower right corner labeled "and then a miracle occurs". The basic part is the mapping from /dev into /dev/lxc/container. That should be doable based on the rules in the host and a basic udev trigger along with a simple mapping configuration. The "given container-specific" part becomes a morass if it gets complicated enough. What I was envisioning was a very simple system of container specific {match} and {map} objects. If a name or symlink passed to the daemon from a udev trigger matched a match, then the name and symlinks and additional maps would be mapped into the appropriate container subdirectory. That works real well if the container and host udev rules are congruent. The tough part is the "container-specific" rules which was the part I specifically mentioned that I had no clue how to make happen. That's a non-trivial task if the container is allowed to make arbitrary udev rule changes based on what they are allowed to receive from the host (and how do we trigger the changes in the host when a change is made in the container). It's easily doable where the container rules are congruent with the host rules. Where they are orthogonal gets much more complicated. But... All that being said, I will take the congruent solution as a starting point (and that will not be an 80% solution - it will be more like a 95% solution) and we can argue about the corner cases and deltas after that. Doable, yes, for some value of doable. I like what Greg was saying about using libudev but I'm totally in the dark as to how to effectively hook that or if it would even work in the container. That one is not in my realm. > -serge Regards, Mike -- Michael H. Warfield (AI4NB) | Desk: (404) 236-2807 Senior Researcher - X-Force | Cell: (678) 463-0932 IBM Security Services | mhw-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org mhw-UGBql2FAF+1Wk0Htik3J/w@public.gmane.org 6303 Barfield Road | http://www.iss.net/ Atlanta, Georgia 30328 | http://www.wittsend.com/mhw/ | PGP Key: 0x674627FF