interfaces/builtin: add dbus-bind interface

[jdstrand]

This implements dbus-bind in support of 'Apps can't own session bus names'. The bug report recommended this as a starting point for discussion:

plugs:
  my-dbus-bind:
    interface: dbus-bind
    system:
    - org.gnome.Foo
    session:
    - org.gnome.Bar

This branch implements that except I switched plugs and slots. I did this because I was thinking about how the DBus bind to a well-known name suggests the snap is providing a service for other snaps to use and envisioned connecting snaps together, much like how we are doing with the mpris interface. Then I got to thinking about it and decided to implement the plugs side so that we could connect apps and have them talk over dbus. Eg, a gnome app might do:

name: gnome-logs
slots:
  dbus-bind:
    session:
    - org.gnome.Logs

Then another gnome app that wants to talk to gnome-logs would do:

name: gnome-logs-consumer
plugs:
  dbus-bind:
    session:
    - org.gnome.Logs

gnome-logs is allowed to bind to org.gnome.Logs after install so it needs nothing extra, but gnome-logs and gnome-logs-consumer need to be connected with snap connect gnome-logs:dbus-bind gnome-logs-consumer:dbus-bind. On classic systems this is still in effect, but we also allow unconfined to talk to the service (like we did with mpris).

As a result, this is actually a generalized way for snaps to coordinate and connect via DBus that doesn't require privileged access to the system. It intentionally doesn't worry about auto-start and DBus policy files since those sorts of things are handled by the DBus backend. We could in theory auto-connect snaps that are from the same publisher like we did with the content interface if that is interesting for people.

I think people were initially thinking that this interface would be transitional and only for classic, but I don't think it needs to be since it is a way to connect snaps together in interesting ways. That said, we probably want to adjust the review tools for the native case to warn (ie, human review) when the name attribute does not end with $SNAP_NAME to avoid namespace collisions (note, we could enforce snap.$SNAP_NAME.*, but the world has settled on reverse domain names for dbus well-known names so we should at least begin thinking about that. Note 2, ending with $SNAP_NAME is of course imperfect because people could choose whatever reverse domain they want). We could also simply trigger a manual review if specifying dbus-bind as a slot until we decide how to work all this out.

Fixes: LP#1590679

[niemeyer]

This seems a bit strange, or perhaps I just misunderstand what it is. The name "bind" implies we're allowing the snap to bind into the given location, of course. But then what is a "consumer of a dbus bind service", and what are we allowing the plug to do here?

Note that just like we don't have a generic "file" interface, we also probably don't want a generic "dbus" interface that allows anything at all to communicate with anything at all without a slightly more well defined context.

[jdstrand]

First off, this PR represents an exploration of what we could do, why that might be good and the considerations around it.

This is implementing a generic dbus interface. The bind allows binding to a given location, as you mentioned, and we could stop there to unblock gnome apps which I think is what people were expecting. However, I implemented that and got to thinking "why are these gnome apps doing this?" and came to the conclusion that it was so that they could integrate with the shell and the user's session, so I added 'unconfined' rules for that. Then it occurred to me that if we stopped there we would have a bug request next week or next month saying "gnome apps can't interoperate with each other" so I implemented how to connect snaps together in the manner described by this PR.

Now, interfaces are a form of contract and this particular contract is extremely loose-- all it says is once connected you can communicate with whatever methods you want. In practice this is 'probably' ok because this will be used with freedesktop.org standards and stuff 'probably' won't break. But 'probably' is again not a strong contract. I mentioned that we could explore the concept of auto-connecting based on if the publisher matches, and I think if we use this generic approach we should do this (much like with the content interface).

So as an exploration, this is interesting and while I was implementing this I was inspired by the content interface since I think there are many parallels. Where the content interface says "here is a location with a bunch of stuff I assume you know what to do with", the dbus-bind interface says "here is a well-known dbus name with an API I assume you know how to use". If we treat dbus-bind similarly in terms of auto-connecting, I was able to imagine a gnome ecosystem really starting to take off-- ie, gnome developers have a content snap and they develop gnome snaps that autoconnect to this content snap, and those developers may use dbus-bind in their snaps and they autoconnect. Beyond gnome, I thought this might be useful for KDE (snaps from KDE devs), Ubuntu Personal (from Canonical devs), etc. Also, like with the content sharing interface, the user is allowed to manually connect snaps from different publishers at their discretion.

I'm happy to adjust this PR as necessary to scale it back, put more constraints, go another direction, etc as we continue to explore this concept.

[niemeyer]

Note that the content interface is constrained to snaps of the same publisher only, or specially whitelisted cases.

That said, perhaps we can build something more generic for dbus, based on the fact we get the name of the interface allowed.

Let's discuss that at the sprint.

[niemeyer]

Same as above. Sounds like this is becoming "dbus" rather than "dbus-bind".

[jdstrand]

From another thread:

"On Wed, 2016-07-27 at 10:37 +0200, Gustavo Niemeyer wrote:

It's not clear to me we want to have that general dbus interface yet. It's
convenient, as it unblocks at once every single dbus use case. The
unfortunate side of doing so is that we lose some clarity and control at
the snapd level.

The alternative to that is having proper interfaces.. for example,
"network-manager", "location-control", etc.
"

The case of network-manager and location-control is clear: these are bona-fide services that many applications need and a proper interface is desired. Indeed, we have interfaces for those already. :)

What I was exploring in the dbus-bind PR was that some desktop environments promote the use of well-known dbus names for their leaf applications so that the applications better integrate into the desktop environment and applications within that environment can access each other more freely (AIUI). This is a design decision of these desktop environments.

If we extend the thinking of 'proper interfaces' to these leaf applications, it means that we will have an interface for Terminix, Rhythmbox, Evolution, Totem, Kmail, etc, etc. I don't think that is particularly useful or desired because new applications in these environments will always need new interfaces, we'll always be in the way and the number of interfaces will be unwieldy. I personally don't want to go down that path.

As mentioned in the PR, we can get out of the way fast by simply allowing the bind but not the communication which is what we discussed in the bug (and why the interface is named 'dbus-bind' currently). The snap itself should then function fine as a leaf application. If there is concern about the interface being too generic, this is the approach I would recommend.

I'd still like people to consider thinking about this more in terms of how we think about content sharing though. Since these well-known dbus names are being registered for a reason (to better integrate), it makes some sense to support that for snaps from the same publisher so that gnome devs can create a proper gnome experience with their snaps, and kde devs can create a proper kde experience with their snaps. Implementation-wise, we do something akin to the exploration in the PR, but we limit the connections to be from the same publisher.

In that light, I agree that 'dbus-bind' may not be quite right for the name, but I think 'dbus' may be too generic of a name for the interface because we aren't supporting all of what dbus can do, only app to app communications through a well-known name. I'm not sure what the alternative would be... dbus-app? (kinda icky but at least hints at what it is trying to do)

[jdstrand]

From another thread:

"On Wed, 2016-07-27 at 10:37 +0200, Gustavo Niemeyer wrote:

It's not clear to me we want to have that general dbus interface yet. It's
convenient, as it unblocks at once every single dbus use case. The
unfortunate side of doing so is that we lose some clarity and control at
the snapd level.

The alternative to that is having proper interfaces.. for example,
"network-manager", "location-control", etc.
"

The case of network-manager and location-control is clear: these are bona-fide services that many applications need and a proper interface is desired. Indeed, we have interfaces for those already. :)

What I was exploring in the dbus-bind PR was that some desktop environments promote the use of well-known dbus names for their leaf applications so that the applications better integrate into the desktop environment and applications within that environment can access each other more freely (AIUI). This is a design decision of these desktop environments.

If we extend the thinking of 'proper interfaces' to these leaf applications, it means that we will have an interface for Terminix, Rhythmbox, Evolution, Totem, Kmail, etc, etc. I don't think that is particularly useful or desired because new applications in these environments will always need new interfaces, we'll always be in the way and the number of interfaces will be unwieldy. I personally don't want to go down that path.

As mentioned in the PR, we can get out of the way fast by simply allowing the bind but not the communication which is what we discussed in the bug (and why the interface is named 'dbus-bind' currently). The snap itself should then function fine as a leaf application. If there is concern about the interface being too generic, this is the approach I would recommend.

I'd still like people to consider thinking about this more in terms of how we think about content sharing though. Since these well-known dbus names are being registered for a reason (to better integrate), it makes some sense to support that for snaps from the same publisher so that gnome devs can create a proper gnome experience with their snaps, and kde devs can create a proper kde experience with their snaps. Implementation-wise, we do something akin to the exploration in the PR, but we limit the connections to be from the same publisher.

In that light, I agree that 'dbus-bind' may not be quite right for the name, but I think 'dbus' may be too generic of a name for the interface because we aren't supporting all of what dbus can do, only app to app communications through a well-known name. I'm not sure what the alternative would be... dbus-app? (kinda icky but at least hints at what it is trying to do)

[jdstrand]

Based on conversation outside of this PR, it sounds like:

• we should only allow the bind for now, not the communication. Once we understand better what might communicate with one another, we can add back the communication
• future assertions work will allow for auto-approval once the assertion is granted for binding to this interface. In the short term, adjust the review tools to do a cheap check (if snapname is 'foo' and bind interface is 'bar', auto-approve, else manual)
• the interface could be named 'dbus-app', comments? While we aren't going to allow communications today, it seems we want to some day. Therefore I think 'dbus-app' makes a lot of sense.

I'm going to close this PR and submit another one so that the code surrounding communications/etc can be more easily referred back to.

[jdstrand]

The new PR for dbus-app is #1613