Re: [lxc-devel] [RFC PATCH 00/11] Add support for devtmpfs in user namespaces

[Greg Kroah-Hartman <gregkh@linuxfoundation.org>]

On Thu, May 15, 2014 at 05:42:54PM +0000, Serge Hallyn wrote:
> What exactly defines '"normal" use case for a container'?

Well, I'd say "acting like a virtual machine" is a good start :)

> Not too long ago much of what we can now do with network namespaces
> was not a normal container use case.  Neither "you can't do it now"
> nor "I don't use it like that" should be grounds for a pre-emptive
> nack.  "It will horribly break security assumptions" certainly would
> be.

I agree, and maybe we will get there over time, but this patch is nto
the way to do that.

> That's not to say there might not be good reasons why this in particular
> is not appropriate, but ISTM if things are going to be nacked without
> consideration of the patchset itself, we ought to be having a ksummit
> session to come to a consensus [ or receive a decree, presumably by you :)
> but after we have a chance to make our case ] on what things are going to
> be un/acceptable.

I already stood up and publically said this last year at Plumbers, why
is anything now different?

And this patchset is proof of why it's not a good idea.  You really
didn't do anything with all of the namespace stuff, except change loop.
That's the only thing that cares, so, just do it there, like I said to
do so, last August.

And you are ignoring the notifications to userspace and how namespaces
here would deal with that.

> > > Serge mentioned something to me about a loopdevfs (?) thing that someone
> > > else is working on.  That would seem to be a better solution in this
> > > particular case but I don't know much about it or where it's at.
> > 
> > Ok, let's see those patches then.
> 
> I think Seth has a git tree ready, but not sure which branch he'd want
> us to look at.
> 
> Splitting a namespaced devtmpfs from loopdevfs discussion might be
> sensible.  However, in defense of a namespaced devtmpfs I'd say
> that for userspace to, at every container startup, bind-mount in
> devices from the global devtmpfs into a private tmpfs (for systemd's
> sake it can't just be on the container rootfs), seems like something
> worth avoiding.

I think having to pick and choose what device nodes you want in a
container is a good thing.  Becides, you would have to do the same thing
in the kernel anyway, what's wrong with userspace making the decision
here, especially as it knows exactly what it wants to do much more so
than the kernel ever can.

> PS - Apparently both parallels and Michael independently
> project devices which are hot-plugged on the host into containers.
> That also seems like something worth talking about (best practices,
> shortcomings, use cases not met by it, any ways tha the kernel can
> help out) at ksummit/linuxcon.

I was told that containers would never want devices hotplugged into
them.  What use case has this happening / needed?

thanks,

greg k-h