Hello,
I’m working on an snap that registers to receive and handle PropertiesChanged events from Spotify over the mpris DBus interface. The app inspects and processes track metadata as tracks are played and skipped by the user in Spotify. I believe this is the last hurdle to overcome before my snap can finally work in strict confinement. I am hoping someone can help me out.
The mpris plug is in place and connected. And the snap is able to access Spotify’s mpris interface without any problems:
$ snap connections testapp
Interface Plug Slot Notes
audio-playback testapp:audio-playback :audio-playback -
desktop testapp:desktop :desktop -
mpris testapp:mpris spotify:spotify-mpris manual
… except receive PropertiesChanged events as reported in the logs:
dbus-daemon[2438]: apparmor="DENIED" operation="dbus_signal" bus="session" path="/org/mpris/MediaPlayer2" interface="org.freedesktop.DBus.Properties" member="PropertiesChanged" name=":1.179" mask="receive" pid=363757 label="snap.testapp.testapp" peer_pid=10453 peer_label="snap.spotify.spotify"
Looking at interfaces/builtin/mpris.go, I only see (send) policies for PropertiesChanged:
dbus (send)
bus=session
interface=org.freedesktop.DBus.Properties
path=/org/mpris/MediaPlayer2
member=PropertiesChanged
peer=(label=###PLUG_SECURITY_TAGS###),
Would it be possible for the mpris interface to allow snaps to receive PropertiesChanged events? My problem seems similar to the one reported in the following link, but for (receive) rather than (send): Error trying to comunicate with Spotify via DBus
Thank you.
Is there anyone that can help me with this post? Even if it’s just to let me know if I didn’t include enough info or posted in the wrong section. I am new to snapscraft, but I think this is a reasonable request (unless there is a security issue I missed). The only alternative I have at this point is to code my app to poll the properties on the mpris interface periodically and detect the changes myself. But that feels counterproductive, knowing that the PropertiesChanged signal exists for that purpose. Thank you very much.
FYI I have re-implemented my app to poll properties over D-Bus every 500ms to get around this permission problem. This is obviously not an ideal solution, considering the properties source snap is capable of notifying (via the PropertiesChanged signal) when its properties change, but unfortunately I can’t use that signal. I’ll monitor https://github.com/snapcore/snapd/blob/master/interfaces/builtin/mpris.go and update my code if the policy is relaxed in the future.
I am not a snapd developer and so I am not comfortable making the change and creating a PR. So the best I could do was ask. Cheers.
Hi, your request sounds perfectly reasonable to me and clearly described, sorry it went unnoticed on the forum. And thanks for taking time to package your app as a snap. I’ll prepare a PR for snapd to update mpris interface, let’s see how it goes.
1 Like
Thank you so much! I am getting close to releasing my app. I love Snapcraft, I just never anticipated the amount of work required to package a desktop app as a strict snap. On the other hand, I think the benefits far outweigh those efforts. At this point I plan to always release my apps as snaps.
1 Like
Here is a tentative PR: https://github.com/snapcore/snapd/pull/11100
If you can push your snap to edge or beta channel then I can make a quick test of this change (just tell me what to check to know it works).
1 Like
Ok, I was able to verify this change with a custom-built snap of dbus-monitor, so should work with your snap as well.
1 Like
Excellent, thanks again for the quick resolution! I should now be able to switch my service implementation back to using the PropertiesChanged signal, and ditch my properties polling timer. I will update my snapd to edge and test, once the PR is merged.
Great, this has just been merged, so should be in snapd from edge ~tomorrow. Just keep in mind that it may take a few weeks until it is in stable snapd.
1 Like
Hi, I just tested my Snap against snapd from edge and it works perfectly.