Browser not setting itself as the default

popey · 2017-08-04 08:30:55 UTC

On an Ubuntu 17.10 system currently Google Chrome (installed via deb) is my default browser.
I installed brave browser with snap install brave --candidate then launched it from the command line.

As expected brave launches and asks to be made the default.

I say “Use Brave”. I then try clicking a link but this launches in chrome, the previous default, not Brave.

Checking my desktop defaults in system settings, it looks like the button in Brave didn’t actually set itself as the default.

Indeed it doesn’t even appear in the list:-

Is this an Ubuntu desktop bug, a brave bug or a snap bug? Or perhaps all three?

ogra · 2017-08-04 11:09:48 UTC

any DENIED messages in syslog ? (my guess would be that the browser-support interface needs some extension to be allowed to set that config value for the desktop session)

popey · 2017-08-07 10:26:20 UTC

I see the following when I launch brave:-

[Mon Aug  7 11:02:14 2017] audit: type=1400 audit(1502101505.795:1514): apparmor="DENIED" operation="mkdir" profile="snap.brave.brave" name="/etc/opt/chrome/" pid=20735 comm="brave" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[Mon Aug  7 11:02:14 2017] audit: type=1400 audit(1502101505.823:1515): apparmor="DENIED" operation="mkdir" profile="snap.brave.brave" name="/etc/opt/chrome/" pid=20754 comm="brave" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
[Mon Aug  7 11:02:14 2017] audit: type=1107 audit(1502101505.875:1516): pid=1107 uid=106 auid=4294967295 ses=4294967295 msg='apparmor="DENIED" operation="dbus_method_call"  bus="system" path="/" interface="org.freedesktop.DBus.ObjectManager" member="GetManagedObjects" mask="send" name="org.bluez" pid=20735 label="snap.brave.brave" peer_pid=1132 peer_label="unconfined"
                            exe="/usr/bin/dbus-daemon" sauid=106 hostname=? addr=? terminal=?'
[Mon Aug  7 11:02:14 2017] audit: type=1400 audit(1502101505.923:1517): apparmor="DENIED" operation="mkdir" profile="snap.brave.brave" name="/etc/opt/chrome/" pid=20776 comm="brave" requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000

But nothing when I press the ‘use brave’ button to make it the default.

jdstrand · 2017-08-07 13:19:18 UTC

Please note that these write accesses for /etc/opt/chrome are pure noise-- the non-root user does not have write access to these directories since /etc is root:root owned. (Ie, if apparmor allowed it, DAC would not).

kalikiana · 2017-08-07 14:31:51 UTC

It seems like the snap disappeared from that channel. But I can still get it from edge.

Running it from Xenial under GNOME Shell, trying to set it as a default, I can see these errors in my terminal:

LaunchProcess: failed to execvp:
xdg-settings
LaunchProcess: failed to execvp:
xdg-settings

However I can see and select it as my browser in Settings > Details.

ogra · 2017-08-07 14:35:12 UTC

smells like we might need something similar to xdg-open here and allow that in the browser-support interface… (a forwarder from the core snap into the user session to call xdg-settings there then)

jdstrand · 2017-08-07 15:48:55 UTC

I agree with @ogra. What I think is happening is that xdg-settings is not in the snap so you get the execvp failure, but then if it was in the snap, it would (presumably) end up changing /home/user/snap/brave/revision/.config/… which won’t influence the default browser of the session. I suspect we need something like xdg-open for xdg-settings because we will want to mediate what snaps can change via an out of process helper, and it can modify the session default application set.

niemeyer · 2017-08-07 17:17:27 UTC

@jdstrand We also need to think through the implications of allowing snaps to hook themselves up as default. It doesn’t feel like something that should be done from inside out.

jdstrand · 2017-08-07 18:18:03 UTC

@niemeyer - I agree. I’m not sure what this would look like for applications that already use xdg-settings (thankfully, it appears to typically only be the browsers (though they all seem do it)).

To me, this feels similar to interface connections where the user can issue a snap command to make a browser the default on the system. Not sure how to hook that into xdg-settings, if at all.

Perhaps one way to do it would be snapd has an xdg-settings that is called, but instead of silently granting the request, the user is prompted graphically by snapd’s xdg-settings. This is getting into the area of ‘contextual prompting for interface connections’, so may want to think about xdg-settings in that context as well.

jdstrand · 2017-10-20 16:56:46 UTC

Also see my comments in Setting a snap of a browser as the default

jamesh · 2017-10-23 09:13:52 UTC

So, snapd already lets an application advertise itself as handling a particular mime type or URL scheme via the MimeType key in its desktop file. The question is whether a confined application should be able to manipulate the default associations. That should be enough for a snapped web browser to show up in the “default apps” panel in the control center.

My gut feeling is that they shouldn’t be able to make such a change unilaterally: it potentially lets the application capture information the user did not intend. If we do want to let a confined application initiate such a change, it should probably be done via a portal that confirms the change with the user first (and could potentially remember a “no” decision for a badly behaved app that tries to set itself default every time it is started).

Wimpress · 2017-10-23 11:08:57 UTC

@jamesh I think what you’ve proposed sounds like a good end goal solution.

However, the current situation is that browsers prompt users to make the browser the default. Browser vendors have this capability today using debs and rpms etc. While this capability is missing from snaps they are reluctant to ship snaps of their browsers.

Perhaps an interim solution is to create a xdg-settings interface that provides the capability to set the default browser, among other things. This could be a manually connected interface, which can be automatically connected via assertions for trusted publishers, and would be a faster route to unblocking browser vendors while preserving the option to implement more fine grained user controls in the future. Thoughts?

jamesh · 2017-10-23 11:09:30 UTC

I filed a bug against xdg-desktop-portal suggesting this here:

I don’t think it is worth trying to build an interim solution for the time before we get xdg-desktop-portal support working: trying to build a parallel system with user prompting, etc is probably more work.

jamesh · 2017-10-23 13:30:09 UTC

So, the main things that block the xdg-settings and xdg-mime utilities from working at the moment are:

$HOME inside the sandbox is a different directory to outside, so ~/.config/mimeapps.list is something else.
if xdg-mime was modified to find the real home directory, the AppArmor confinement would need to allow it to read and write the mimeapps.lst file plus the temporary file used to update it.

And as mentioned above, there is no way to e.g. allow changing the default email client without changing everything else.

oSoMoN · 2017-10-23 15:58:59 UTC

I confirm that the chromium snap does show up in the default apps panel in gnome-control-center.

mvo · 2017-10-24 10:36:15 UTC

I like the suggestion from @jdstrand to handle this similar to how we deal with xdg-open. I.e. to have a xdg-settings binary inside the core snap that proxies to the outside and handle the actual requests via snap userd. I created a a first branch with how this could look like: https://github.com/snapcore/snapd/pull/4073