snapd support for xdg-desktop-portal

Bug #1680011 reported by Harald Sitter on 2017-04-05
This bug affects 4 people
Affects Status Importance Assigned to Milestone

Bug Description

Also see forum topic

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.

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


Simon Fels (morphis) on 2017-04-05
tags: added: cross-distro
Simon Fels (morphis) wrote :

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 so we can discuss it with a wider audience of developers and users. Can you create a topic there for this?

description: updated
description: updated
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers