GNOME Background App Permissions via XDG Portals

Modern Linux desktop environments prioritize sandboxing and user privacy, making background execution control a vital security feature. The GNOME desktop manages background app permissions primarily through XDG Desktop Portals—specifically utilizing the Background portal API. This mechanism bridges sandboxed applications (such as Flatpaks) and the host system, giving users transparency and control over which applications can continue running without an open window or launch automatically upon system startup.

The Role of XDG Desktop Portals

XDG Desktop Portals function as secure intermediaries between sandboxed environments and host system resources over the D-Bus inter-process communication system. The primary portal framework consists of two main components:

  1. xdg-desktop-portal: The generic, desktop-agnostic frontend daemon that provides standard D-Bus interfaces to applications.
  2. xdg-desktop-portal-gnome: The backend implementation specific to GNOME that interfaces directly with the GNOME Shell, Mutter window manager, and native desktop settings.

When an application wants to run in the background or register an autostart command, it makes a request to the org.freedesktop.portal.Background interface rather than executing directly on the host system.

How the Background Permission Workflow Works

The interaction follows a structured lifecycle involving permission checks, user consent, and persistence storage:

1. Permission Requests via D-Bus

When an app without a visible window attempts to keep running, it calls the RequestBackground method on the portal. The request typically includes metadata, such as a reason for needing background execution and whether the app also requests permission to autostart with the system.

2. Verification Against the Permission Store

The portal checks the host's Permission Store database (xdg-permission-store).

  • If the user has already granted or denied the background capability for that specific application identifier, the portal enforces the existing rule immediately.
  • If no record exists, GNOME presents a system dialog prompting the user to allow or deny the background execution request.

3. State Enforcement and Sandboxing

For sandboxed applications like Flatpaks, isolation rules strictly prevent the process from bypassing the portal. If background permissions are denied, the runtime limits the application's ability to maintain detached background worker processes or establish autostart entries.

GNOME Shell Integration and User Visibility

GNOME handles background processes visually through built-in desktop indicators and system settings:

  • Background Apps Menu: Introduced in GNOME 44, the Quick Settings menu includes a dedicated "Background Apps" section. This monitor displays active applications that have no open graphical windows. If an app runs without an active window, GNOME Shell queries the portal system to identify and display it, allowing users to forcefully terminate it directly from the interface.
  • Control via Settings: Users can manage background permissions retroactively through GNOME Settings under the "Apps" panel. Here, permissions granted via the XDG portal can be toggled on or off individually for each application.
  • Autostart Tracking: When an application receives background permission that includes autostart privileges, the portal writes the appropriate .desktop entries into the user’s designated config directory (~/.config/autostart), which GNOME tracks using systemd user sessions.

By routing lifecycle requests through XDG Desktop Portals, GNOME removes an application's ability to silently persist in the background, enforcing explicit user consent and unified system-level visibility.