[Devel] [lxc-devel] Device Namespaces

[Michael H. Warfield]

On Tue, 2013-10-01 at 15:46 -0500, Serge Hallyn wrote: 
> Quoting Eric W. Biederman (ebiederm at xmission.com):
> > "Serge E. Hallyn" <serge at hallyn.com> writes:
> > 
> > > Quoting Andy Lutomirski (luto at amacapital.net):
> > >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen <janne.karhunen at gmail.com> wrote:
> > >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> > >> > <gregkh at linuxfoundation.org> 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 at linux.vnet.ibm.com mhw at wittsend.com
6303 Barfield Road           | http://www.iss.net/
Atlanta, Georgia 30328       | http://www.wittsend.com/mhw/
                             | PGP Key: 0x674627FF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 482 bytes
Desc: This is a digitally signed message part
URL: <http://lists.openvz.org/pipermail/devel/attachments/20131001/e1eda7c7/attachment-0001.sig>