Hi there, after installing Spotify as a snap app on ubuntu 18.04 one cannot log in.
I have a facebook login, this means that normally spotify opens a URL in the browser for authentication.
Tough this does not seem to work -> no reaction after “Log in with facebook”
does someone have a work around?
info:
snap 2.29.4.2+18.04
snapd 2.29.4.2+18.04
series 16
ubuntu 18.04
kernel 4.14.0-13-generic
Gtk-Message: Failed to load module "gail"
Gtk-Message: Failed to load module "atk-bridge"
Gtk-Message: Failed to load module "canberra-gtk-module"
Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.215" (uid=1000 pid=13264 comm=“dbus-send --print-reply --session --dest=io.snapcr” label=“snap.spotify.spotify (enforce)”) interface=“io.snapcraft.Launcher” member=“OpenURL” error name="(unset)" requested_reply=“0” destination=“io.snapcraft.Launcher” (bus)
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
Error org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type=“method_call”, sender=":1.217" (uid=1000 pid=13271 comm=“dbus-send --print-reply --session --dest=io.snapcr” label=“snap.spotify.spotify (enforce)”) interface=“io.snapcraft.Launcher” member=“OpenURL” error name="(unset)" requested_reply=“0” destination=“io.snapcraft.Launcher” (bus)
Error org.freedesktop.DBus.Error.ServiceUnknown: The name com.canonical.SafeLauncher was not provided by any .service files
[1229/102512.216549:ERROR:gl_context_glx.cc(239)] Couldn’t make context current with X drawable.
[1229/102512.217769:ERROR:gles2_cmd_decoder.cc(4330)] GLES2DecoderImpl: Context lost during MakeCurrent.
[1229/102512.219720:ERROR:gles2_cmd_decoder.cc(4325)] GLES2DecoderImpl: Trying to make lost context current.
[1229/102512.219824:ERROR:gles2_cmd_decoder.cc(4325)] GLES2DecoderImpl: Trying to make lost context current.
[1229/102512.219989:ERROR:gl_context_glx.cc(239)] Couldn’t make context current with X drawable.
Wat is
name com.canonical.SafeLauncher ?
Can’t reproduce this bug on
$ snap version
snap 2.30
snapd 2.30
series 16
ubuntu 17.10
kernel 4.13.0-21-generic
I’ve also refreshed to core 2.29.4.2 (in stable) and I can’t reproduce it there either. Perhaps this is a bug on Ubuntu 18.04? Can someone else confirm that? 
yeah, seems like to be a 18.04 problem as Mailspring also does not open URL links there.
Can you test other snaps (like Mailspring and Discord)? Do URLs fail to open there too? Might be a problem with this work.
See Launching URLs in snapped applications no longer works in 18.04 and mark yourself as affected by the linked bug
We can reproduce this issue on 18.04 and it appears to be a regression or new behaviour of dbus activated services in 18.04 (snap userd is such a service).
Ah, mvo be me to it. Doing some testing it looks like an activation issue.
One curious (perhaps the bug itself) aspect is that in the denial we don’t have the peer= definition. For instance in the case of using gimp to open online documentation:
sty 15 15:34:45 kaedwen dbus-daemon[1242]: apparmor="DENIED" operation="dbus_method_call" bus="session" path="/io/snapcraft/Launcher" interface="io.snapcraft.Launcher" member="OpenURL" mask="send" name="io.snapcraft.Launcher" pid=5773 label="snap.gimp.gimp"
I’ll investigate dbus daemon next.
I used a debug build of dbus-daemon started as a separate session bus with DBUS_VERBOSE=1. I pointed a snap execution environment at that new session and tried to activate snap userd by running xdg-open. The call was blocked by apparmor as before and there was not a single extra line of logs in an otherwise very verbose dbus-daemon.
There’s a new Ubuntu patch in bionic version of dbus that touches the way confinement is detected. It seems the new version supports both the regular apparmor-based detection (this is what the patch contains, it’s marked as not-for-upstream) and via the new dbus container awareness that snapd is not using yet.
Offtopic: will this be a problem for dbus in Debian?
I managed to get a debug setup working. For anyone trying this, this is what works:
install dbus-tests and replace your /usr/bin/dbus-daemon with a shell script (stash the original binary as dbus-daemon.real:
#!/bin/sh
export DBUS_VERBOSE=0
exec /usr/lib/dbus-1.0/debug-build/bin/dbus-daemon "$@"
Now reboot your system and wait for gdm to start. Don’t log in just yet (in gdm). Use ssh to log in remotely and flip DBUS_VERBOSE=1. Log in in gdm now. Doing this naively will probably fail for you (unless you have a very fast machine) as the amount of logging is so huge you will hit dbus message response timeouts and things will fall apart.
Disable things that like to chatter over dbus, in my case I just disabled wifi.
Open a terminal and having installed a snap (I used the gimp snap) run:
snap run --shell gimp
In another terminal start collecting logs with, journalctl -f | tee bug.log
In the first terminal that is now waiting in the gimp execution environment run:
xdg-open http://example.org
Wait for it to fail and then interrupt journalctl.
This is the log I got: https://paste.ubuntu.com/26393163/
And @jdstrand already found the interesting part:
19:12 < jdstrand> sty 15 19:10:15 kaedwen dbus-daemon[2413]: 2413: 0x7f86619c78c0: 1516039815.743271 [bus/activation.c(1803):bus_activation_activate_service] activation not authorized:
org.freedesktop.DBus.Error.AccessDenied: An AppArmor policy prevents this sender from sending this message to this recipient; type="method_call", sender=":1.74" (uid=1000 pid=4280
comm="dbus-send --print-reply --session --dest=io.snapcr" label="snap.gimp.gimp (enforce)") interface="io.
It looks like dbus is not correctly looking up the peer label.
EDIT: CC @tyhicks who wrote the apparmor patch for dbus in bionic.
For some context, the patch header is this:
From: Tyler Hicks <tyhicks@canonical.com>
Date: Fri, 15 Aug 2014 13:37:15 -0500
Subject: Add DBus method to return the AA context of a connection
Allows the AppArmor label that is attached to a D-Bus connection to be
queried using the unique connection name.
For example,
$ dbus-send --print-reply --system --dest=org.freedesktop.DBus \
/org/freedesktop/DBus \
org.freedesktop.DBus.GetConnectionAppArmorSecurityContext string::1.4
method return sender=org.freedesktop.DBus -> dest=:1.50 reply_serial=2
string "/usr/sbin/cupsd"
[Altered by Simon McVittie: survive non-UTF-8 contexts which
would otherwise be a local denial of service, except that Ubuntu
inherits a non-fatal warnings patch from Debian; new commit message
taken from the Ubuntu changelog; do not emit unreachable code if
AppArmor is disabled.]
Forwarded: not-needed
Looks like that commit could have to do with the issue
https://cgit.freedesktop.org/dbus/dbus/commit/?id=dc25979eb
Thanks Seb. Looks like we just need to add AssumedAppArmorLabel=unconfined to the .service file and things will start to work (untested). Someone should verify that adding this doesn’t break earlier releases that don’t support the field.
Hmm, I’m not sure I understand that comment @jdstrand - which service should have that extra definition?
I can add and test this shortly, I want to do some more debugging on the bionic package with some extra logging added.
Sorry for necro-posting here, but I’m seeing this on my debian install:
snap 2.48.2
snapd 2.48.2
series 16
debian -
kernel 5.9.0-5-amd64
Symptoms are the same as for OP: clicking on “log in with facebook” opens no browser ==> no login possible.
Which is a shame because spotify also seem to have stopped updating their debian repo last september, and the latest version from there is too old to authenticate against facebook.