Re: [lxc-devel] Device Namespaces

["Michael H. Warfield" <mhw-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>]

[-- Attachment #1.1: Type: text/plain, Size: 4401 bytes --]

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" <serge-A9i7LUbDfNHQT0dZR+AlfA@public.gmane.org> writes:
> > 
> > > Quoting Andy Lutomirski (luto-kltTT9wpgjJwATOyAt5JVQ@public.gmane.org):
> > >> On Tue, Oct 1, 2013 at 7:19 AM, Janne Karhunen <janne.karhunen@gmail.com> wrote:
> > >> > On Thu, Sep 26, 2013 at 8:33 AM, Greg Kroah-Hartman
> > >> > <gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r@public.gmane.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-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

[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 482 bytes --]

[-- Attachment #2: Type: text/plain, Size: 205 bytes --]

_______________________________________________
Containers mailing list
Containers-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org
https://lists.linuxfoundation.org/mailman/listinfo/containers