Message-ID: <CAHr-LraFeEwmkf4eS2xh=b7PvJfvcFHiyF7tN5YfizPe3oW3kQ@mail.gmail.com>
Date:	Wed, 24 Jun 2015 22:45:57 +0200
From:	Alexander Larsson <alexander.larsson@...il.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	David Herrmann <dh.herrmann@...il.com>,
	Djalal Harouni <tixxdz@...ndz.org>,
	Greg KH <gregkh@...uxfoundation.org>,
	Havoc Pennington <havoc.pennington@...il.com>,
	"Eric W. Biederman" <ebiederm@...ssion.com>,
	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
	Tom Gundersen <teg@...m.no>, Daniel Mack <daniel@...que.org>
Subject: Re: kdbus: to merge or not to merge?

On Wed, Jun 24, 2015 at 9:43 PM, Andy Lutomirski <luto@...capital.net> wrote:
> On Wed, Jun 24, 2015 at 10:11 AM, Alexander Larsson
> <alexander.larsson@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists