systemd Wants to Know Which App Is Talking to It. That Is a Bigger Deal Than It Sounds

The Linux desktop has never had a clean answer to a simple question. When an app asks a system service for your camera, your microphone, or your location, which app is actually asking, and is it allowed to. A new systemd component called systemd-appd is a proposal to fix exactly that, and the reaction to it says as much about how Linux is governed as about the code itself. I want to walk through what it does, the real mechanism underneath it, and why a sensible piece of plumbing turned into an argument.

The problem is that Linux cannot reliably tell who is asking

Picture a sandboxed app, packaged as a Flatpak, asking PipeWire to access your microphone. The service on the other end needs to know 2 things. Which process is this, exactly, and which application does it represent. Linux has been surprisingly bad at both.

The classic way to identify the process on the other end of a socket was to ask the kernel for its process ID. The trouble is that a process ID can be recycled. The process you were talking to exits, the number gets handed to something else, and now your security check is pointing at the wrong program. That is a real race condition that has bitten real software. The modern fix is a mechanism called SO_PEERPIDFD, which hands a service a pidfd, a stable handle that refers to one specific process and cannot be confused with a later one that happens to reuse the number. Services like polkit and the system journal are the exact cases it was built for.

Knowing the process is only half of it. You still have to map that process back to an application identity, which sandbox launched it, what it is called, and what it is permitted to do. Flatpak, the packaging format that bundles an app with its libraries so the same build runs on any distribution, makes this harder because the sandbox deliberately hides the app from the services it talks to. That gap is what systemd-appd is meant to close.

Figure 1. A sandboxed app asks a service for the microphone. Without a shared identity service, the service cannot reliably tell which app is asking or what it is allowed to do. Source: Author diagram based on the systemd-appd proposal

What systemd-appd actually proposes

The component was drafted as a systemd pull request by Adrian Vovk, one of the developers working on the next generation of Flatpak, and it had been discussed openly for about a year before that. The systemd project describes it plainly. systemd-appd is a centralized place to keep track of the user’s apps, and it lets session services like D-Bus, PipeWire, portals, and Wayland compositors reliably identify apps and learn about their current permissions.

The flow is straightforward. An app registers when it starts, systemd-appd records its identity and its permissions, and any service that needs to make a security decision can query appd over a well defined interface and skip the guesswork. When a request lands, the service can ask appd which application this is, then check whether that application has been granted the camera or the microphone, and hand the user a clear choice. The permission information becomes something the whole desktop shares, so each service no longer reconstructs it on its own.

Vovk has been clear that appd is tightly coupled to systemd by design, since it leans on systemd’s own tracking of the user’s service hierarchy and talks to it over internal IPC, which is the argument for shipping it inside systemd and not as a separate project. It is also described as a prerequisite for 3 things the Flatpak developers want next, nested sandboxing where a sandboxed app can safely spawn another sandbox, proper PipeWire support, and finally removing the old D-Bus proxy that Flatpak has leaned on for years.

Figure 2. How systemd-appd fits in. The app registers once, and every session service queries one identity and permission authority with no guesswork of its own. Source: Author diagram based on systemd PR 43885

How the identity actually attaches

The mechanism underneath is worth seeing, because it is where the systemd coupling comes from. When an app launches, appd places it in a systemd unit that follows the XDG naming convention for applications, the standard scheme that gives an app a stable reverse domain name like org.mozilla.firefox. Putting the app in that unit does more than organize it. The app’s identity gets tagged onto the control group, the cgroup, that contains its processes, so the identity travels with the process tree, where a separate lookup table could drift out of sync.

Services then talk to appd over a Varlink interface, a simple request and reply protocol systemd already uses for its internal APIs. A service holds a pidfd for the process that contacted it, hands that to appd, and gets back the application identity and its current permissions. The reason Adrian Vovk argues appd belongs inside systemd is exactly this chain. appd leans on systemd’s own tracking of your service hierarchy and its cgroup machinery, and a component that reaches that deep into systemd internals is awkward to ship anywhere else.

Figure 3. How the identity attaches. The app launches into a systemd unit, its identity is tagged onto the cgroup, and any service hands appd a pidfd over Varlink to learn who the app is and what it may do. Source: Author diagram based on systemd PR 43885 and Phoronix

One detail matters for the panic that followed the announcement. Vovk has said appd is not meant to become a hard requirement for D-Bus or PipeWire. Those services would query appd for permissions when it is present and enforce them, and keep working when it is absent. The dependency is softer than the headlines made it sound, though a non systemd distribution that wanted the same features would still need to provide a drop in replacement exposing the same interface.

This is the model Android and macOS already have

None of this is new as an idea. It is the app permission model that mobile and macOS users see constantly. On macOS you get the prompt asking whether Chromium can find devices on your local network, and you can tap deny and watch the browser keep working fine, because the request was optional and the system gave you the choice. That machinery has a name, TCC, short for Transparency, Consent, and Control, and it traces each request up the call chain to the app actually responsible for it before deciding.

Android is the cleaner parallel, and it is worth seeing exactly how it works, because it solves the same problem systemd-appd is chasing. When you install an Android app, the system hands it its own Linux user ID. The kernel then enforces isolation by that ID, so one app cannot touch another’s files, and every granted permission is recorded in a central store that services read. When an app asks for your location, the location service asks the permission service whether that app’s user ID holds the location permission, a stable check that a recyclable process ID could never give. Checking a stable identity is the whole point, because a process number can be recycled under you, and it is the same move systemd-appd is making on the desktop. Windows has its own version of this for packaged apps.

Linux has had pieces of this for a while, portals that broker access to files and devices, polkit for privileged actions, the sandbox boundaries that Flatpak draws, but it has lacked a single shared notion of application identity that all of those pieces agree on. Each guard at each layer has its own way of working out who you are. systemd-appd is an attempt to give them a common answer, so a permission dialog on Linux can finally say this request comes from this app, and this app is or is not allowed to do that.

Figure 4. Android, macOS, and Windows each give apps a strong identity that system services can check. Linux has the pieces but no shared identity authority, which is the gap systemd-appd targets. Source: Author comparison of platform app identity models

The spying fear misses the real objection

A chunk of the online reaction jumped straight to systemd is building a tracker to spy on you. I think that reading is wrong. appd stores which apps are running and what they are allowed to do so that your own desktop can enforce permissions, which is the opposite of surveillance, it is the machinery that lets you deny the microphone in the first place. Android and macOS keep the same kind of record, and nobody calls their permission manager spyware.

The objection worth taking seriously is about centralization. systemd started life as an init system, the first process that boots your machine and starts your services. Over the years it has absorbed login session management, network configuration, DNS resolution, container management, and more. Each addition had a reasonable justification, and each one also made systemd harder to avoid. Adding an application identity and permission authority continues that pattern, moving one more piece of core desktop infrastructure inside the systemd tent.

Figure 5. systemd began as an init system and has steadily absorbed login, networking, DNS, and container management. appd would add app identity and permissions to that list. Source: Author timeline of systemd scope

The part that actually affects distributions

This is the part that reaches real users. If Flatpak comes to depend on systemd-appd, and the Flatpak developers have said appd is a prerequisite for the features they are building, then distributions that do not use systemd have a problem. Alpine, Void, Guix, and Devuan all ship without it, and a cross distribution packaging format depending on 1 specific init system cuts against the entire promise of Flatpak, which is build once and run anywhere.

There is precedent for how this goes. When systemd’s login manager, logind, became a requirement for modern desktops, non systemd distributions forked it into a standalone daemon called elogind just to keep their desktops working. A similar split could happen again, with those distributions maintaining a downstream shim, a replacement, or simply losing full Flatpak support. The counterargument is real too. systemd already manages the user’s service hierarchy and already has the cgroup machinery appd needs, most mainstream distributions already run it, and reinventing that foundation somewhere neutral would be a large amount of work for a problem many users will never notice.

Where this actually stands

systemd-appd is early. It is a draft proposal under review, current stable Flatpak does not require it, and no distribution ships it yet. What it represents is clearer than its final form. Linux is trying to grow a real application identity layer, the thing that lets a permission prompt mean something, and the most practical place to build it happens to be the component that already tracks your running services. That convenience is also the concern, because the more the desktop leans on systemd, the harder systemd becomes to replace. Both of those things are true, and the next few months of review will decide which one the Linux world weighs more heavily.