snapd support for xdg-desktop-portal

[Harald Sitter]

Also see forum topic https://forum.snapcraft.io/t/snapd-support-for-xdg-desktop-portal/161

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.
In particular, from a KDE point of view I think we would be much happier only having to maintain one set of host-level UI helpers for contained applications, so since xdg-desktop-portals are already being used and we already have UI backing for it we'd much rather move ahead with that.

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.

http://flatpak.org/xdg-desktop-portal/portal-docs.html

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 [1]. The helper then uses a backend such as the kdeframeworks one [2] 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.Print` and `org.freedesktop.portal.Screenshot` there could also be an interface only giving access to screenshotting).

As a second step the existing code at [1] 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 [1] it seems to rely on a metadata file `.flatpak-info` in `/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 :)

[1] https://github.com/flatpak/xdg-desktop-portal
[2] https://cgit.kde.org/xdg-desktop-portal-kde.git

[Simon Fels (morphis)]

Thanks for bringing this up!

As this is more a architectural thing rather than a bug it would be great if you can bring this over at https://forum.snapcraft.io/ so we can discuss it with a wider audience of developers and users. Can you create a topic there for this?

[Maciej Borzecki (maciek-borzecki)]

This is being discussed here: https://forum.snapcraft.io/t/snapd-support-for-xdg-desktop-portal/161

[Zygmunt Krynicki (zyga)]

GTK and Qt snaps packaged with recent enough versions of the toolkit as well as running on recent-enough desktop stacks will now use portals automatically, Snapd exposes access to the document portal, and work on integration with other portals is in progress.

I'm marking this as fix released. Please feel free to reopen if I missed something essential that was required.