@niemeyer I am thinking about this now for some time. Let me summarize where we are and what my thoughts on this are so far:
As of today
dbus-send today which sends a call to snapd-xdg-open which runs in the context of the session of the user executing
xdg-open. If root calls
dbus-send call will go nowhere as root doesn’t have a dbus session bus.
g_app_info_launch_default_for_uri which only makes sense in the context of a user session. It uses the MIME database to find the right application to execute for a given URI.
Your proposal is now to add a subcommand to
snapctl which will handle a given link. This fine so far. However, if
snapctl is called from the context of a user session we loose all user session information once the REST API call arrives at snapd. We then have no further way to translate the call back to the calling user-session. As the call to
g_app_info_launch_default_for_uri needs to be initiated from within a user session and in the unconfined area we can’t do this from within snapd.
To solve this problem we need something running inside the user session which we can pass the link a snap gives to
snapctl open-link to. Until now this was snapd-xdg-open. If we don’t want this to be named snapd-xdg-open anymore we could invent something like
snapd --user which runs inside a user session (started by upstart on 16.04 or
systemd --user on other distributions).
snapd --user would then keep a connection to snapd to receive further instructions like an
open-link command from snapctl which it then would pass this over to either the real
xdg-open binary on the host or
g_app_info_launch_default_for_uri. With this we still need something we can use inside
snapd to identify a
snapd --user instance from a