Also see bug report: https://bugs.launchpad.net/snappy/+bug/1680011
It has been suggested that it would be a good idea to support xdg portals as used by flatpak to facilitate host⇄confinement interaction for common use cases such as opening a URI or opening a file.
The advantage is that the wheel doesn’t need to get reinvented for snapd as this use case and the way it should work can be exactly the same regardless of the actual distribution/confinement tech. Be it flatpak or snap or whatever.
The biggest limitation of snaps we experience right now is that they can’t get access to host files. xdg-desktop-portals solves this problem nicely and in addition, adds some cross-desktop dbus API to do common desktop application stuff such as sending a notification.
The way it works is that the confined application needs access to the portal service on the dbus session bus under
org.freedesktop.portal.Desktop. This service is provided by the xdg-desktop-portal helper. The helper then uses a backend such as the kdeframeworks one to carry out user interaction using host-mechanism rather than snap mechanism (e.g. the host opens the file-open dialog rather than the snapped app itself).
So, from a snapd POV all it would need to get started is a xdg-desktop-portal interface giving access to org.freedesktop.portal.* for snaps. Technically a more fine-grained interface set up may be possible (i.e. since the abilities of the portal are scoped by separate interfaces such as
org.freedesktop.portal.Screenshot there could also be an interface only giving access to screenshotting).
As a second step the existing code of xdg-desktop-portal probably should be revised for flatpakism. I’ve already seen an execve to
flatpak run and hardcoded use of flatpak’s metadata. These cases seem fairly isolated, so it’s more a matter of finding them and adding logic to attempt using snap if/when applicable.
Lastly, file IO needs to be looked at. From a quick look at the relevant code it seems to rely on a metadata file
/proc/$pid/root to get a bunch of data (naturally that probably should grow support for snap metadata). The most relevant date is the “app_id” which in turn is used by the documents system to provision the file access. If all goes well the helper comes back to the contained application with a URI in /run/user/$UID/doc/, so this will also need to be read-writable trough the snapd interface. Additionally, I think “app_id” results in further nesting within that /run path to isolate apps from one another. That’s just a guess though so some testing is in order there