Messages in this thread | | | Date | Thu, 16 Apr 2015 14:13:44 +0200 | Subject | Re: [GIT PULL] kdbus for 4.1-rc1 | From | David Herrmann <> |
| |
Hi
On Wed, Apr 15, 2015 at 8:12 PM, James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > For me the biggest issue is the container problem: it's really hard to > containerise kdbus because of the stateful nature of the protocol and > the fact that it has a well known system bus. Separation into domains > works for OS containers, but application containers need more fluidity. > It's not unlike the same problem on windows: Windows application > containers are very difficult to do because the global registry means > that OLE handlers all have to run inside your container as well > (effectively making it an OS container). I'm sure, since we already > have a lot of containers people going to plumbers, that we can get them > to turn up for the discussion.
kdbus actually works very well in OS containers that mount a new kdbusfs inside the container. This new instance of kdbus will be entirely seperated from any other on the system. We've designed it that way especially with OS containers in mind. This is explained in kdbus.fs(7). It's very similar to devpts' container support, where you mount a new instance of devpts into each container instance you run.
For Docker-style (i.e. app-focused) containers, it's a more complex story. kdbus will not solve this for you, but at least one thing deserves being mentioned: for this kind of sandboxing kdbus certainly makes things *easier*, compared to dbus1. Why? because the kernel gains a notion of individual messages and method call transactions, something that is completely unavailable if you stick to dbus1 where all the kernel sees is a raw stream of AF_UNIX/SOCK_STREAM bytes. In fact, kdbus as it is right now even contains minimal but explicit support for sandboxing, by allowing creation of multiple bus endpoints to the same bus that carry additional, more restrictive policy.
Thanks David
| |