Quoting Eric W. Biederman (ebiederm@xxxxxxxxxxxx): > "Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > > > Quoting Andy Lutomirski (luto@xxxxxxxxxxxxxx): > >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen <janne.karhunen@xxxxxxxxx> wrote: > >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman > >> > <gregkh@xxxxxxxxxxxxxxxxxxx> 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). -serge _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/containers
