systemd-appd cambia il desktop Linux: app e permessi sotto controllo

Linux sta cercando da tempo un modo più affidabile per stabilire con precisione a quale applicazione appartiene davvero a un determinato processo. Con desktop moderni, sandbox, servizi D-Bus, PipeWire, portali e compositor Wayland, ricavare quell’informazione non è sempre semplice. Il problema diventa ancora più delicato quando la risposta serve per decidere se un programma può usare una videocamera, accedere a un dispositivo o compiere un’altra operazione privilegiata. systemd-appd è il nuovo componente di systemd proposto per concentrare in un unico servizio l’identità delle applicazioni in esecuzione e i relativi permessi.

Sebastian Wick e Adrian Vovk ne parlavano già nel 2025 durante il lavoro sul futuro di Flatpak e sul progetto indicato informalmente come Flatpak-Next. A ottobre 2026 la proposta ha però fatto un passo molto più concreto: Vovk ha pubblicato una pull request nel repository di systemd con una prima implementazione funzionante. Al momento in cui scriviamo il codice è ancora in revisione, quindi non si tratta di una funzionalità già consolidata nelle distribuzioni.

L’introduzione di systemd-appd potrebbe avere conseguenze che vanno ben oltre Flatpak. D-Bus, PipeWire, i portali desktop e i compositor Wayland potrebbero interrogare lo stesso servizio per capire chi sta chiedendo una certa operazione e quali autorizzazioni possiede in quel preciso momento. systemd-appd prova a trasformare l’identità di un’applicazione in un’informazione esplicita e interrogabile, invece di costringere ogni componente del desktop a ricostruirla con metodi differenti.

Cosa cambia davvero con systemd-appd

Un programma desktop non coincide necessariamente con un singolo processo. Può generare processi figli, usare helper, avviare componenti tramite altri servizi oppure passare attraverso launcher che eseguono successivamente una chiamata exec(). Guardare soltanto PID (process ID), nome dell’eseguibile o percorso del file non garantisce quindi di ottenere un’identità applicativa stabile.

systemd possiede già una struttura utile: i processi delle applicazioni possono vivere all’interno di specifiche unità utente e dei relativi cgroup. La documentazione dedicata all’integrazione con i desktop environment definisce una convenzione per i nomi delle unità applicative: systemd-appd sfrutta proprio questa convenzione. Quando un’applicazione si registra, il servizio controlla che il processo appartenga a un’unità conforme allo schema previsto e associa quell’identità all’istanza in esecuzione.

Il vantaggio di systemd-appd sta soprattutto nel fatto che introduce una sorta di identità comune dell’applicazione. Se un programma prova ad aprire la videocamera, accedere al microfono o utilizzare una risorsa protetta, il componente che deve autorizzare l’operazione può risalire con maggiore affidabilità all’app che ha effettuato la richiesta.

Oggi questa informazione può essere ricostruita in modi differenti a seconda del servizio coinvolto: PipeWire, D-Bus, i portali desktop e il compositor non necessariamente vedono l’applicazione nello stesso modo. Il risultato è una gestione più complessa, soprattutto quando entrano in gioco sandbox e permessi dinamici.

Con systemd-appd l’idea è invece offrire un punto comune da interrogare: “questa richiesta arriva dall’app X e, in questo momento, X possiede questi permessi“. PipeWire continuerà, ad esempio, a controllare l’accesso ai flussi audio e video; systemd-appd fornisce però informazioni più coerenti sull’identità del programma che sta chiedendo di usarli.

Perché Flatpak è soltanto il punto di partenza

Come osservato nell’introduzione, il lavoro nasce in buona parte dalle discussioni su Flatpak-Next, dove una migliore identificazione delle applicazioni può semplificare sandboxing, portali e gestione delle autorizzazioni. Ma il meccanismo proposto non è legato esclusivamente alle app Flatpak.

In prospettiva può servire a qualunque applicazione integrata con le convenzioni previste da systemd per la sessione desktop. Invece di aggiungere un altro strato specifico di Flatpak, systemd-appd prova a fornire un’infrastruttura utilizzabile da più componenti del desktop Linux.

Non si tratta però di un registro delle applicazioni installate, né di un nuovo package manager: systemd-appd non nasce per elencare pacchetti RPM, DEB, Flatpak o Snap presenti sul computer. Tiene piuttosto traccia delle istanze applicative attive, della loro identità e delle informazioni necessarie ai servizi che devono prendere decisioni sui permessi.

Una piccola modifica che potrebbe pesare molto

systemd-appd è ancora in revisione e può cambiare tanto prima di arrivare nelle distribuzioni: impossibile, quindi, descriverlo come un componente ormai acquisito del desktop Linux.

L’impostazione sembra però essere evidente: si vuole dare alle applicazioni un’identità riconoscibile e condivisa tra i servizi della sessione.

E non è una questione limitata a chi sviluppa software perché tocca temi sempre più importanti per gli utenti: accesso a videocamera e microfono, sandbox, isolamento delle app e gestione granulare dei permessi.

Linux non ha bisogno soltanto di sapere quali processi stanno funzionando sul sistema. Deve anche sapere, con sufficiente affidabilità, quale applicazione rappresentano e cosa quella applicazione è autorizzata a fare. systemd-appd prova a proporsi proprio come il pezzo mancante tra queste due informazioni.