Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757223AbbDPMNw (ORCPT ); Thu, 16 Apr 2015 08:13:52 -0400 Received: from mail-qg0-f42.google.com ([209.85.192.42]:35234 "EHLO mail-qg0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754513AbbDPMNp (ORCPT ); Thu, 16 Apr 2015 08:13:45 -0400 MIME-Version: 1.0 In-Reply-To: <1429121536.2187.44.camel@HansenPartnership.com> References: <20150413190350.GA9485@kroah.com> <20150413204547.GB1760@kroah.com> <20150414175019.GA2874@kroah.com> <20150414192357.GA6107@kroah.com> <21805.29994.968937.364993@quad.stoffel.home> <20150414215135.GC6801@home.goodmis.org> <20150415083714.GD16381@kroah.com> <1429121536.2187.44.camel@HansenPartnership.com> Date: Thu, 16 Apr 2015 14:13:44 +0200 Message-ID: Subject: Re: [GIT PULL] kdbus for 4.1-rc1 From: David Herrmann To: James Bottomley Cc: Greg Kroah-Hartman , Jiri Kosina , Steven Rostedt , John Stoffel , Andy Lutomirski , Linus Torvalds , Andrew Morton , Arnd Bergmann , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , "linux-kernel@vger.kernel.org" , Daniel Mack , Djalal Harouni , "Paul E. McKenney" Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2118 Lines: 40 Hi On Wed, Apr 15, 2015 at 8:12 PM, James Bottomley 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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/