Apps can't own session bus names (unity7 interface)

[Robert Ancell]

Many applications require to own a name on the session D-Bus. This is often used for app uniqueness and D-Bus launching (e.g. many GNOME apps).

For example (lp:~ubuntu-desktop/+junk/gnome-mahjongg-snap) attempting to run gives:

$ /snap/bin/gnome-mahjongg
Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.141" is not allowed to own the service "org.gnome.gnome-mahjongg" due to AppArmor policy

I would expect the unity7 interface to allow bus name ownership so these apps can work.

[Sebastien Bacher (seb128)]

That's something most of GNOME apps do nowadays ... Jamie, Tyler, do you know if it would be easy to allow that in the unity7 apparmor rules?

[Mark Shuttleworth (sabdfl)]

On 09/06/16 17:41, Sebastien Bacher wrote:
> That's something most of GNOME apps do nowadays ... Jamie, Tyler, do you
> know if it would be easy to allow that in the unity7 apparmor rules?

I bet we can make an interface which lets the snap own an explicit bus
name, yes.

I don't think we yet have parameterized interfaces, but perhaps the bus
name could be forced to be the same as the snap name in the first cut
(and later we add the ability to specify a particular bus name).

I would make this a separate, orthogonal interface to unity7 so it can
be used more widely than just Unity.

Mark

[Gustavo Niemeyer (niemeyer)]

We already do that today for existing interfaces. But I wonder if we should open up a slightly wider door for name registration on the session bus specifically (IOW, not system session, not communication), so that applications can run even if they don't bother about interfaces. This would unblock applications from being published confined, and it would not break the interface model because to communicate they'd still an interface.

[Jamie Strandboge (jdstrand)]

The reason why GNOME apps (and others) do this is to communicate with arbitrary apps within the user's session. This is because the old world uses a distro model that assumes a trusted archive and therefore everything in the user's session is trusted and everything can do anything to interoperate. Of course, the new world changes that, apps are not trusted by the system and must communicate via defined interfaces. We are going to continue to bump up against applications designed for the old world trust model when running them in the new world.

All that said, I was thinking the same thing Gustavo was-- we definitely can add a dbus bind rule to the unity7 interface and Gustavo is right that simply binding does not allow communication. The only problem then is controlling what the app can bind to, which is what Mark's idea tries to address. We could simply not care but this would mean that an app could perform a DoS against other apps or against session services by binding to names it shouldn't. I'm not sure of the proper solution for this but was thinking along the same thing Mark was-- limiting it somehow to the snap name and likely in a separate interface with an attribute. This is actually pretty similar in concept to what we did in snappy 15.04 with 'bus-name' but what we found with 'bus-name' is that the well-known bus name that existing applications use not the same as the snap name. In this particular example, the snap name is gnome-mahjongg but the dbus name is org.gnome.gnome-mahjongg. Since this is mostly something with GNOME apps, we could call this 'gnome-app-bind' (or something with 'gnome' in the name) and allow binding to org.gnome.<SNAPNAME> which would fix this bug. Of course then we have things like Rhythmbox which binds to several: org.gnome.Rhythmbox3, org.gnome.UPnP.MediaServer2.Rhythmbox, org.mpris.MediaPlayer2.rhythmbox or evolution: org.gnome.Evolution, org.gnome.EvolutionAlarmNotify. There just isn't a standard well-known dbus name naming convention.

Ok, so moving forward I think we have a few options:
1. don't worry about name collisions and bind to anything in unity7
2. since we know these are gnome apps, create a gnome dbus interface that allows binds to org.gnome.**
3. come up with a parameterized interface and have snaps declare what to bind to and have snapd refuse installing snaps that collide

'2' isn't much of an improvement over '1' based on d-feet output-- there are a ton of session services and apps that start with org.gnome.*.

I'm not sure we can do much better than '3' with these old world apps. If parameterized interfaces are a ways off and we want to do '3', I suggest implementing the interface without parameters (ie, the default) that allows binding to anything today. Then when the parameterized bits are added, we adjust the review tools to trigger a manual review if the snap doesn't specify the attribute. In this manner existing apps don't break and apps can transition to using attributes.

[Mark Shuttleworth (sabdfl)]

Can we have an interface which is "bind to the user session dbus", and
then evolve it to add parameters, being a list of the names you want to
actually bind? That way we could start appropving those apps now with
"any" use dbus name, and evolve over time to require that they itemise
their interfaces?

Upon reflection I think $SNAPNAME is a red herring, its too inflexible
and too difficult to predict over time.

Mark

[Jamie Strandboge (jdstrand)]

@Mark: yes we can and this is what I was suggesting. Add an interface without parameters that allows anything. Iterate on parameters in the fullness of time.

I suggest calling this interface, dbus-session-bind. Opinions?

[Mark Shuttleworth (sabdfl)]

Opinions! Always! How about 'session-dbus-bind' ? :)

[Gustavo Niemeyer (niemeyer)]

If it's a blank check, I don't see many advantages over asking for unity7 itself. Once we want to force the declaration, we can just introduce the actual interface.

Might also be a good thing because unity7 will eventually be deprecated, and we might use that timeframe to deprecate the general binding together with it.

Also note that as far as there's no serious security implication, such "DoSing" would not be a big deal. Badly behaving applications that wedge the system for no good reason can just be removed and not used.

[Mark Shuttleworth (sabdfl)]

On 10/06/16 06:36, Gustavo Niemeyer wrote:
> If it's a blank check, I don't see many advantages over asking for
> unity7 itself. Once we want to force the declaration, we can just
> introduce the actual interface.

My only reason for an orthogonal interface was so that we don't end up
duplicating the same with gnome-shell and elementary etc.

Mark

[Sebastien Bacher (seb128)]

@Jamie, GNOME apps tend to follow that convention but it's an xdg spec
https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-1.1.html#dbus

"The application must name its desktop file in accordance with the naming recommendations in the introduction section (e.g. the filename must be like org.example.FooViewer.desktop). The application must have a D-Bus service activatable at the well-known name that is equal to the desktop file name with the .desktop portion removed (for our example, org.example.FooViewer). The above interface must be implemented at an object path determined as follows: starting with the well-known D-Bus name of the application, change all dots to slashes and prefix a slash. For our example, this is /org/example/FooViewer."

Basically GNOME/freedesktop is trying to standardise on the reverse-DNS naming scheme and to enforce that for the .desktop/dbus service/schemas/etc. Seems like flatpak is relying on the package to use the same name, so similar to the idea suggested earlier (https://github.com/flatpak/flatpak/issues/50) ... that's nice in theory, in the real world lot of softwares don't follow those convertions (yet?) and I'm unsure how it can work with the case where and applications has different dbus names though...

[Jamie Strandboge (jdstrand)]

@Gustavo, if we are moving towards a separate interface and forcing a declaration via attributes, I'd prefer introducing that interface now with default to anything because if we add it to unity7, we can't remove it once apps start using it without breaking apps. With the new interface with defaults to any name, we can transition to using attributes by having store reviews force use of the attributes and manual review when using defaults for new uploads-- but the interface still supports the default for old uploads so nothing breaks.

[Gustavo Niemeyer (niemeyer)]

That's a very good point, Jamie. Let me sleep over that, please, to ponder whether there's something else entirely that we could do.

[Jamie Strandboge (jdstrand)]

@Gustavo, have you had a chance to ponder this?

[Simon Fels (morphis)]

Just for interest I did such a simple interfaces some time ago for playing:

dbus-name:
https://github.com/morphis/snappy/commit/0489b6f23b190d817975247d460990f67e0c4d5c

Allows you to bind a by attribute specified dbus name on the system bus. This was meant for snap internal communication but could be easily expanded to specify system/session bus and integrate some snapd management to avoid bus name collisions.

[Gustavo Niemeyer (niemeyer)]

As we discussed today on the channel, we should give a try at using attributes to produce the final interface we want here. This is supported for some time, and really not too much work compared making the interface global.

I suggest something like this (whitespaces => underlines to make Launchpad happy):

plugs:
____my-dbus-bind:
________interface: dbus-bind
________system:
____________- org.gnome.Foo
________session:
____________- org.gnome.Bar

Not completely sure about the "dbus-bind" name yet. Must research upstream terminology to make sure we're talking about the right idea here. We can review this on the PR though, assuming the remaining of the plan sounds sane.

[Jamie Strandboge (jdstrand)]

This looks fine to me. Will propose a PR and we can iterate there.

[Jamie Strandboge (jdstrand)]

@Robert: I have a preliminary branch but the mahjongg example in the description doesn't work-- it segfaults in devmode as well as strict (strict has no security policy denials thus far). Can you provide an updated example I can test against? Ideally the example would include the app itself and instructions on how to use the DBus interface the app is providing.

[Sebastien Bacher (seb128)]

@Jamie you should be able to test with https://code.launchpad.net/~ubuntu-desktop/+junk/gnome-logs-snap

[Jamie Strandboge (jdstrand)]

Thanks Seb, I'm able to use this to test the new interface.

Unrelated to this bug, you should:
  plugs:
  - unity7
  - gsettings
  - log-observe

then after install you would do:
$ sudo snap connect gnome-logs-udt:log-observe ubuntu-core:log-observe

I need to fix the bug in log-observe to allow reading the systemd logs in addition to /var/log/* and will be doing that very soon.

[Alberto Mardegan (mardy)]

Please have a look at bug 1633520; I believe that there could be a way to solve both bugs at once (my suggestion is on comment #2 there).

[Jamie Strandboge (jdstrand)]

FYI, the interface is now designed and I'll be working on the implementation now. This design solve's Robert's immediate problem (this bug) but also KDE's desire for snap interactions via DBus as well as providing a foundation for future improvements for interface implementations.

Using Robert's snap as an example, he would use in his snapcraft.yaml:

name: gnome-mahjongg
slots:
  mahjongg:
    interface: dbus
    bus=session
    name=org.gnome.gnome-mahjongg

For full details, please see https://github.com/snapcore/snapd/pull/1613#issuecomment-261350004 (don't worry that the PR is closed-- that is only temporary until I implement the new design).

[Jamie Strandboge (jdstrand)]

FYI, https://github.com/snapcore/snapd/pull/1613 is updated for the new design and ready for review.

[Robert Ancell (robert-ancell)]

While this bug is about session bus names the linked PR will also solve ownership of system bus names, correct?

[Jamie Strandboge (jdstrand)]

@Robert, it does, yes, but system services may be best served by a dedicated interface (it would depend on the service).

[Jamie Strandboge (jdstrand)]

FYI, as of today https://github.com/snapcore/snapd/pull/1613 has no blockers it should hopefully land this week.

[Jamie Strandboge (jdstrand)]

This has landed and will be in snapd 2.20. Please see https://github.com/snapcore/snapd/wiki/Interfaces#dbus for details.

[Jamie Strandboge (jdstrand)]

2.20 fixes this issue.

[XiaoGuo, Liu (liu-xiao-guo)]

Gtk-Message: Failed to load module "canberra-gtk-module"
Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Connection ":1.141" is not allowed to own the service "com.timxx.XMRadio" due to AppArmor policy

Now, I see the same issue in my application. I cannot see any messaging by using the snappy-debug. Is this fixed already?

[XiaoGuo, Liu (liu-xiao-guo)]

My version of snap is:

$ snap --version
snap 2.23.1
snapd 2.23.1
series 16
ubuntu 16.04
kernel 4.4.0-67-generic

[Jamie Strandboge (jdstrand)]

This is issue fixed if you use the dbus interface. See https://github.com/snapcore/snapd/wiki/Interfaces#dbus for details. You might also be interested in this thread: https://lists.ubuntu.com/archives/snapcraft/2017-January/002339.html

[XiaoGuo, Liu (liu-xiao-guo)]

Thanks! I will have a try. This is something new to me:)

[XiaoGuo, Liu (liu-xiao-guo)]

@Jamie, there is one question here. For a snap application, can I use "slots" directly in the case? I view "slots" a service provider or producer. I do not have the case using a plug in the app.

Thanks

[Jamie Strandboge (jdstrand)]

Yes! :) I think it is helpful to think about what the application is doing. It is binding to a well-known name so that other processes can access it through the well-known name. In other words, it can be thought of as a service. In snappy terms, it is a slot implementation of a service for the DBus apis the service provides under the well-known DBus name.

Due note that if the snap is being distributed via the Ubuntu public store, then the initial upload will require a human to grant use of this well-known name, but once that is done, subsequent uploads aren't blocked.

[XiaoGuo, Liu (liu-xiao-guo)]

In my case, I just use this service inside the app. No other apps use it
but making the apparmor error gone away. My snapcraft.yaml is at:

https://github.com/liu-xiao-guo/xmradio/blob/master/snap/snapcraft.yaml

Thanks for your explanation.

On Thu, Mar 23, 2017 at 11:16 PM, Jamie Strandboge <email address hidden> wrote:

> Yes! :) I think it is helpful to think about what the application is
> doing. It is binding to a well-known name so that other processes can
> access it through the well-known name. In other words, it can be thought
> of as a service. In snappy terms, it is a slot implementation of a
> service for the DBus apis the service provides under the well-known DBus
> name.
>
> Due note that if the snap is being distributed via the Ubuntu public
> store, then the initial upload will require a human to grant use of this
> well-known name, but once that is done, subsequent uploads aren't
> blocked.
>
> --
> You received this bug notification because you are subscribed to the bug
> report.
> https://bugs.launchpad.net/bugs/1590679
>
> Title:
> Apps can't own session bus names (unity7 interface)
>
> Status in Snappy:
> Fix Released
> Status in snapd package in Ubuntu:
> Fix Released
>
> Bug description:
> Many applications require to own a name on the session D-Bus. This is
> often used for app uniqueness and D-Bus launching (e.g. many GNOME
> apps).
>
> For example (lp:~ubuntu-desktop/+junk/gnome-mahjongg-snap) attempting
> to run gives:
>
> $ /snap/bin/gnome-mahjongg
> Failed to register: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied:
> Connection ":1.141" is not allowed to own the service
> "org.gnome.gnome-mahjongg" due to AppArmor policy
>
> I would expect the unity7 interface to allow bus name ownership so
> these apps can work.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/snappy/+bug/1590679/+subscriptions
>

--
XiaoGuo, Liu