Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751327AbbFXUqG (ORCPT ); Wed, 24 Jun 2015 16:46:06 -0400 Received: from mail-wi0-f174.google.com ([209.85.212.174]:38200 "EHLO mail-wi0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750876AbbFXUp6 (ORCPT ); Wed, 24 Jun 2015 16:45:58 -0400 MIME-Version: 1.0 In-Reply-To: References: Date: Wed, 24 Jun 2015 22:45:57 +0200 Message-ID: Subject: Re: kdbus: to merge or not to merge? From: Alexander Larsson To: Andy Lutomirski Cc: Linus Torvalds , "linux-kernel@vger.kernel.org" , David Herrmann , Djalal Harouni , Greg KH , Havoc Pennington , "Eric W. Biederman" , One Thousand Gnomes , Tom Gundersen , Daniel Mack 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: 4759 Lines: 99 On Wed, Jun 24, 2015 at 9:43 PM, Andy Lutomirski wrote: > On Wed, Jun 24, 2015 at 10:11 AM, Alexander Larsson > wrote: >> My name is on the dbus specification, and I am (and was >> then) well aware of systems with object references. In fact, both >> previous ipc systems (Corba ORBs) that Gnome used before we designed >> dbus uses object references, and they had a lot of problems which dbus >> solved for us. I'm not saying dbus is perfect, but it has its reasons >> for the way it works. >> >> So, dbus-the-system has some kind of notion of an object reference >> (peer + object path), but the *bus* is fundamentally a way to >> communicate between peers, and the object path is merely some >> uninterpreted metadata. > > I'm talking about the reference part, not the object part. Peer + > object path is a name, not a reference. True, its not a reference in the "refcount" style. >> You wish that the kernel controlled access to a particular object in a >> peer, but once the message is dispatched into the target process all >> bets are off anyway. It will be running some code parsing your message >> in the process with no real separation from the other objects. Any bug >> there could give you wider access. I don't see how this fundamentally >> makes the whole system much more secure. On the other hand, I *do* >> remember having to track down cross-process leaks from circular >> references between processes using Corba... > > If you have peer ids keeping things alive on dbus, surely you can also > have circular references, no? Technically you could set up a situation where this happens, but in practice it doesn't really. Because object paths don't keep other processes alive you don't accidentally get circular references, whereas this happened a lot on corba because references was the only thing you had. >> You can run three instances of an app, but only one of them can own >> the bus name. This works out fine if your app does not use dbus, but >> it may be a problem if it uses dbus activation. > > I'd really like to be able to xdg-app --stateless oowriter > some_untrusted_file.docx and have it fully functional, including > printing, even if I have another instance running. If that was to work then you'd have to have a way to make all the session services that are needed for it to work to also listen to the new custom bus for only that app. >> Well, the service providers are not the same as the portals. Say you >> have a twitter client that you want to register to be able to share >> some selected text. The twitter client can be fully sandboxed. The >> portal is just the link between the requesting app and the list of >> registered share providers. >> > > Ah. I clearly am misunderstanding something. What's a portal? Well, portal is a general name for "service needed for making sandboxed apps work". So, they can be a bit different, but in essence they are small dbus services that facilitate communication between different apps and between the app and the host session, in a safe way. Think of them sort of like filtering proxies, but with a gui. >> Well, that is essentially what a portal like the share one does. >> Although it shows a user controlled UI inbetween to avoid the app >> being able to start any other app it wants. > > Hmm. So shouldn't xdg-app be explicitly choosing which portals are > allowed for which sandboxed apps rather than allowing > org.freedesktop.portal.*? Right now there is no default policy for this, as we don't really have the portal system fully formed yet. But, yeah, using portal.* was an example of a policy, another would be to list the allowed portals explicitly. >> You're free to design such a system and write a desktop to use it. >> However, in Gnome (and in the other desktops as well), dbus is already >> used for all ipc like this and all the freedesktop specs, >> infrastructure, type systems, interfaces, code and frameworks are >> built around that. There has to be a *massive* advantage for us to use >> something else, and I'm not at all convinced by the issues you bring >> up. > > The custom endpoint policy thing is brand new, whereas using a > userspace proxy for xdg-app actually sounds easier than using a > separate kdbus bus. Sticking dbus in the kernel would also be new. Yeah, some code in the middle is new, but the entire infrastructure and sematics are the same. I got the feeling you were proposing something completely different to dbus. -- 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/