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).