Re: Device Namespaces

["Michael H. Warfield" <mhw-BetbSzk+GohWk0Htik3J/w@public.gmane.org>]

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

On Tue, 2013-10-01 at 12:51 -0700, Eric W. Biederman wrote: 
> "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.

Actually, I don't necessarily see that as a problem as much as a
necessity.  If a container can decide when it gets a serial port or
other device, I would think that would constitute a security issue and
container isolation violation.  Restricting what container can have
access to what has to be determined in the host and, once you've drunk
that koolaid, you might as well stuff it in somewhere.  Policy has to be
in the host or you will never get the security corner cases right.

Ultimately, it is the host which is in charge of the hardware and is
managing the containers (it can start them up, shut them down, or manage
them) so, at its base level, is is the responsibility of the host to
manage those devices between the containers.

That being said, there is the additional issue of, what does the
container do when we hand it a device and how do we let it know.  That's
now classically the issue of udev and formerly hotplug and their
predecessors...

> The expectation is that system containers will then run the udev
> rules and send the libuevent event.  

Which makes sense.  Something along the line of a socket into the
container to send selected events from the user space daemon in the host
would make some sense there.

> To make that all work without kernel modifications requires placing
> a faux-udev in the container, that listens for a device assignment from
> outside the container and then does exactly what udev would have done.

> The problems with this that I see are:

> - udev is a moving target making it hard to build a faux-udev that will
>   work everywhere.

Well, it is an it isn't.  Yeah the rules have been changing (I'm getting
tired of the "deprecated" rule warnings) but I've seen worse, much
worse.

> - On distro's running systemd and udev integration is sufficiently tight
>   that I am not certain a faux-udev is possible or will continue to be
>   possible.

Actually, I think that's a non-issue.  IIRC, systemd (now) discontinues
its udev operation when it detects it's in a container.  That was at the
heart of the entire Fedora 15/16 in a container meltdown with the broken
versions of systemd trying to run udev in the container.  What do we do
in place of it?  I don't know.

> - There are two other widely deployed solutions for managing hotplug
>   devices besides udev.

> So given these difficulties I do not believe that the evolution of linux
> device management is done, and that patches to udev, the kernel or both
> will be needed.  While it would be good for testing and understanding
> the problem I don't think a faux-udev will be a long term maintainable
> solution.

> I also understand the point that we aren't talking patches yet and just
> discussing ideas.  Right now it is my hope that if we talk this out we
> can figure out a general direction that has a hope of working.

> From where I am standing faking uevents instead of replacing
> udev/mdev/whatever looks simpler and more maintainable.

> Eric

Mike
-- 
Michael H. Warfield (AI4NB) | (770) 985-6132 |  mhw-BetbSzk+GohWk0Htik3J/w@public.gmane.org
   /\/\|=mhw=|\/\/          | (678) 463-0932 |  http://www.wittsend.com/mhw/
   NIC whois: MHW9          | An optimist believes we live in the best of all
 PGP Key: 0x674627FF        | possible worlds.  A pessimist is sure of it!

[-- 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