A new systemd component is out for review, and it is the kind of thing a desktop only notices when it stops working. The draft pull request for systemd-appd describes “a centralized place to keep track of the user’s apps”: an app management service that gives session services, D-Bus, PipeWire, portals and Wayland compositors among them, one place to reliably identify running apps and learn about their current permissions.
How it works
Apps, or the processes that exec their way into becoming apps, register themselves at startup, and appd starts tracking their identity. It checks that the app runs in a systemd unit that follows the XDG app naming convention, which tags that identity onto the cgroup holding the process. On top of registration, appd stores and retrieves metadata about each app; in the current commit that is just its runtime permissions and entitlements. Session services read it over a Varlink interface and can then decide whether an app should be allowed to take some privileged action. The interface in this first pass covers “basic management of running app instances,” so richer metadata is left to later commits in the series.
The pull request is by Adrian Vovk and spans 49 files and roughly 2,500 added lines so far. It has been open since late September, depends on another open change, and is marked as a draft, so nothing is merging imminently; the thread is active. The request’s own body keeps it short and points to the individual commits for details.
Why it exists
The motivating use case is Flatpak’s next generation: the Flatpak-Next, or Flatpak 2.0, effort needs sandboxed apps and the services around them to agree on identity and permissions, and each service answering that question its own way is the problem this replaces. Sandboxed apps already run across these services today; what is missing is one shared record of what each app is and what it may do. The component was first discussed about a year ago, and the current draft is that plan taking shape. If it lands, the plumbing becomes a systemd-level primitive that other session software can rely on rather than reimplement. Flatpak is the first customer, but the interface is general on purpose: any session service that needs a reliable answer about an app gets the same one.
My read
Nobody picks a desktop over its session bus, and this is exactly the invisible layer where sandboxing either becomes consistent or stays a patchwork. The design is deliberately narrow: identity and permissions held in one service, read by everyone, owned by no one. Whether it sticks depends on review, and systemd review is not fast. Bookmark it rather than react to it.
Source: Phoronix’s report and the draft pull request.