GNOME Shell search providers in snaps

snapd
#1

The desktop team is looking into making it possible to install GNOME Shell search providers as snaps.
Search providers are DBus-activatable applications that implement the org.gnome.Shell.SearchProvider2 DBus interface.

For this to work, each provider needs to install an ini-file that describes the provider (desktop ID, bus name and object path) in a well-known place (e.g. /var/lib/snapd/desktop/gnome-shell/search-providers/), and a DBus service file in a place where DBus will find it (e.g. /var/lib/snapd/desktop/dbus-1/services/).

This means we need hooks in snapd, similar to the one that handles rewriting and installing desktop files in /var/lib/snapd/desktop/applications/. One would rewrite the ini file (DesktopId key) describing the provider and install it in /var/lib/snapd/desktop/gnome-shell/search-providers/. A second hook (or maybe just the same one, that’s an implementation detail) would rewrite the DBus service file (Exec key) and install it in /var/lib/snapd/desktop/dbus-1/services/.

Does this sound like a reasonable proposal? Are there potential security concerns (an unconfined desktop session would be allowed to activate a DBus service in a snap)?

Before we go any further with a proof of concept implementation, we would very much appreciate opinions and feedback from the snapd and security teams. Thanks!

6 Likes
Gnome-shell search providers
[gnome-calculator] Calculator is not integrated with universal search
#2

@jdstrand, @niemeyer: when you have some time to review the proposal, we would love to hear your feedback, before we start prototyping.

#3

Why do you need to implement another search provider? GNOME Shell can already search for snaps through the GNOME Software search mechanism.

#4

This isn’t a proposal to implement a new search provider for snaps. It’s a proposal to enable existing search providers in snaps to be discovered and exposed by GNOME Shell.

#5

Quickly reading through https://developer.gnome.org/SearchProvider/ and your proposal, it sounds like you want to:

  • generate a .desktop file for the search provider with a rewritten Exec line that ensures the provider is launched under confinement. AIUI, this is already implemented with our current .desktop file implementation
  • generate a .service file for dbus activation which has a rewritten Exec line that ensures the provider is launcher under confinement
  • generate an .ini file which maps the DesktopId to the aforementioned .desktop file and maps the BusName to the Name in the aformentioned .service file. This file also specifies ObjectPath

The general concept is generally ok wrt confinement. Do note the search provider is trusted wrt user input and it may not be obvious to people that a snap comes with a search provider that can sniff things. Eg, install the tomboy snap which is both an application and a provider. The user only ever uses tomboy and doesn’t (immediately) know that a provider is quietly listening to all gnome-shell searches. I’m not sure how this should be surfaced to the user-- via a manually connected interface? The provider is disabled by default and must be explicitly enabled? Something else?

You mentioned the desktop services would be in /var/lib/snapd/desktop/dbus-1/services/. This may be ok, but we’ll need to coordinate on this point due to other conversations regarding session services and dbus activation (https://github.com/snapcore/snapd/pull/2592). We need a coherent design for all of it.

Lastly, for a search provider to function at all, it will need to have AppArmor policy allowing it. This could be an extension to the existing dbus interface or another interface.

Basically, in the design we need to reconcile the dbus interface and/or apparmor policy, session services, session service activation and as a special case for activation, shell search providers (even if the initial implementation doesn’t implement all of this). This needs to be done in a developer-friendly way. Looking at the contents of the .service and .ini files, it seems plausible these can be completely autogenerated from the snap.yaml (which would require some work for making the generators and interface code consult each other-- see aforementioned PR for some context).

1 Like
Fwupd snap, needed interfaces
#6

A manually connected interface sounds reasonable to me.

#7

So, we’re part of the way there with a few of my pending PRs. First of all, we’ve got my D-Bus service activation support PR, which will allow the shell to launch the search provider on demand:

https://github.com/snapcore/snapd/pull/6258

Related to the above, I’ve got a PR to allow snaps to provide user daemons:

https://github.com/snapcore/snapd/pull/5822

I think this is the primary way snaps would want to provide session bus services.

At first I thought the only remaining requirement would be for snapd to be able to install search provider .ini files, but that’s not quite it. We also need to be able to support the GApplication/GtkApplication protocol. The main sticking point is that this requires installing a .desktop file that matches the D-Bus name it will acquire on the session bus.

At the moment, snapd installs desktop files named like ${snap_name}_${app_name}.desktop. D-Bus names can not contain underscores, so there is no way these desktop files can be used to implement the GtkApplication protocol.

1 Like
#8

Any news about fix search on gnome shell ?

1 Like
#9

I don’t have anything to report about search providers specifically. The prerequisite features to allow a snap to install activatable D-Bus session bus services was merged though.

That work took longer than I had expected, as we didn’t have a good way to control long running services in the user’s session. So part of that work involved creating a way for snapd to stop those services when snaps are removes, or restart them when snaps are upgraded. It is mostly complete now, with only a few more tasks to have it enabled by default.

With that in place, all that is required is some code to install the configuration file linking the activatable D-Bus service and desktop file for the search provider. I haven’t done any work on this last part, but I don’t see it being particularly contentious compared to what has come before.

1 Like