An initial release of Flatpak portals for GNOME

A framework for sandboxing desktop applications in the GNOME environment has been in development ever since 2013, when Lennart Poettering proposed the idea in a GUADEC session. Subsequently, Alexander Larsson developed the xdg-app system, which relied on lightweight per-application containers linked to more substantial collections of system tools and libraries called "runtimes." The xdg-app container format was recently renamed Flatpak.

To confine an application in such a way that it cannot adversely affect the host, Flatpak needs a sandbox. Currently, it uses a combination of namespaces, control groups, bind mounts, and SELinux. Eventually, secure system services like Wayland are also expected to be part of the sandbox, replacing insecure alternatives like X.

Up until now, however, xdg-app/Flatpak releases have always shipped with the sandboxing feature disabled by default, because there were no mechanisms in place to allow sandboxed applications to access the system resources they would need to function. For instance, if the user clicks on a hyperlink in a sandboxed office application, there would need to be some interprocess communication (IPC) interface in place to open up that link in a web browser. Applications that need to play or record sound need access to the sound card, and so on.

Poettering proposed defining a set of these interfaces in his original plan (modeled after Android's Intents), referring to them as "portals." Specifying and implementing the portals has always been part of the plan, of course, but work on the container format preceded it by necessity.

But, as Matthias Clasen announced on July 8, the first draft of GNOME's portal interfaces has now been unveiled. Along with it, the project has released a set of GNOME components that can be used to test compatible Flatpak application packages.

The portal package itself is named xdg-desktop-portal and implements a D-Bus service running under the name org.freedesktop.portal.Desktop. That service listens for specific requests from applications. In this initial 0.1 release, there are ten portals defined:

• org.freedesktop.portal.Request: a generic interface that is used by the portal service to keep the current portal request alive until it has been completed
• org.freedesktop.portal.FileChooser: an interface applications can use to trigger a file-open dialog
• org.freedesktop.portal.OpenURI: an interface applications can use to initiate opening a URI in a web browser
• org.freedesktop.portal.Print: an interface applications can use to trigger the system print dialog
• org.freedesktop.portal.Screenshot: an interface applications can use to request a screenshot
• org.freedesktop.portal.Notification: an interface applications can use to send a desktop notification to the system or to withdraw a notification
• org.freedesktop.portal.Inhibit: an interface applications can use to inhibit the current desktop session from ending, idling, or suspending (such as might be wanted when the user is running a presentation)
• org.freedesktop.portal.NetworkMonitor: an interface that provides network status information to applications
• org.freedesktop.portal.ProxyResolver: an interface that provides network proxy information to applications
• org.freedesktop.portal.Documents: an interface that provides mediated access to a filesystem to an application

From that list, the FileChooser, OpenURI, Print, Screenshot, and Inhibit portals follow the traditional guidelines used by Android Intents and originally described by Poettering. User interaction is required before the sandboxed application can complete any of the desired actions.

First, the sandboxed application sends a request to the D-Bus portal (such as "let me open a file" to the FileChooser portal) and the portal backend (which we will see in a moment) responds by asking the user to approve the request. If the user agrees, the backend presents the file-open dialog, lets the user select some file, then hands the selected file descriptor back to the sandboxed application. If the user cancels the request at any stage, no file will be opened. By mediating the interaction, the portal mechanism should make it impossible for applications to take actions without the user's knowledge.

The Documents portal is somewhat more complex; its primary purpose appears to be allowing applications to save documents to the filesystem, which in turn can make it necessary to provide some view of the filesystem to the application, as well as features to specify some file attributes. Documents created by the application are stored in a FUSE filesystem mounted inside the sandbox at /run/user/$UID/doc/ so that the application can continue to access them. The FUSE filesystem will also be mounted outside the sandbox, making it accessible with other, non-sandboxed programs.

The NetworkMonitor and ProxyResolver portals are a bit different, in that they do not involve user interaction at all; rather, sandboxed applications are intended to ask for network information and get a reply directly from the backend. Users would, presumably, be informed at install time that the application requires network access. Similarly, the Notification portal does not ask the user's permission for each request; users must place a small amount of trust in the system that desktop notifications are relatively safe. There is more detailed documentation about the D-Bus interfaces available at the Flatpak site.

Accompanying the xdg-desktop-portal release is a corresponding backend implementation for GNOME called xdg-desktop-portal-gtk. It connects to existing GTK+ APIs to respond to the FileChooser, Documents, Print, and OpenURI portals, uses the GNOME Session Manager to respond to the Inhibit portal, and uses GNOME Shell's screenshot and notification facilities to respond to those portals. The NetworkMonitor and ProxyResolver portals are handled by GIO.

In his blog post, Clasen noted that the necessary support for the portals has already been merged and will be released with the 3.22 releases of GTK+ and GNOME. While there are a few existing functions that will stop working for sandboxed applications using the portals (for example, sandboxed applications will not be able to see file-preview images), accessing the core portal functionality should not require any changes on the application's side.

Clasen also pointed out that the initial portal set was chosen because it covers basic, toolkit-level functionality. The next step is defining portals needed by audio/video-capable applications, including access to camera, microphone, and audio-playback hardware. Several other portal proposals are pending as open issues on the repository, such as portals for geolocation information, access to address book contacts, and access to cryptographic keys.

He also said the portals are defined to be desktop-environment neutral, and that work is underway to write backends for KDE/Qt applications as well. Little information is available about that effort so far, but it is early in the process. No doubt the design and details of portals will need to change as developers work with the system in real application projects. Nevertheless, it will be particularly informative to see how the Flatpak project's designs are received by developers working outside of GNOME and GTK+. The Flatpak developers would like the framework to be adopted as widely as possible—a process that will, naturally, require dealing with a fair amount of feedback from projects with their own plans and agendas.