Sul desktop Linux, sapere con certezza quale applicazione si cela dietro un processo è da sempre una questione aperta — e da quella questione dipende chi può accedere alla videocamera, al microfono, alle risorse più sensibili. Adrian Vovk ha proposto systemd-appd, un nuovo componente di systemd che ambisce a diventare il punto di riferimento condiviso per l'identità delle applicazioni e i loro permessi, mettendo fine alla frammentazione tra sandbox, D-Bus, PipeWire e portali. Il codice è ancora in revisione, ma l'idea tocca qualcosa di fondamentale: la coerenza tra ciò che un sistema sa di un
systemd-appd: il nuovo servizio che unifica identità e permessi delle app Linux
Un punto comune da interrogare per sapere chi chiede cosa
Mark
Perché questo problema di identità delle app è rimasto irrisolto per così tanto tempo su Linux?
Mimi
Perché il desktop Linux è cresciuto in modo organico, con componenti diversi—D-Bus, PipeWire, portali—che si sono sviluppati indipendentemente. Ognuno ha dovuto inventarsi un modo per capire quale app stesse facendo una richiesta.
Luke
Ma systemd-appd non è solo un'altra soluzione tra tante? Come farà a diventare lo standard?
Mimi
Perché si appoggia su infrastruttura che systemd già fornisce—le unità utente e i cgroup. Non aggiunge un nuovo strato, usa quello che esiste.
Mark
E Flatpak? È vero che questo nasce da Flatpak-Next?
Mimi
Sì, ma Vovk e Wick hanno capito che il problema è più ampio. Flatpak è solo il punto di partenza. Qualsiasi app che segua le convenzioni di systemd potrebbe usarlo.
Luke
Ancora in revisione, però. Quante cose cambieranno prima che arrivi nelle distribuzioni?
Mimi
Non si sa. È una pull request, non una decisione già presa. I manutentori di systemd potrebbero chiedere modifiche sostanziali.
Mark
Cosa cambia concretamente per un utente che usa Linux?
Mimi
Accesso più coerente a videocamera e microfono, sandbox più affidabili, permessi più granulari e trasparenti.
Luke
Ma oggi come funziona? Cioè, le app riescono comunque ad accedere a queste risorse.
Mimi
Sì, ma il processo è frammentato. Ogni componente controlla l'accesso in modo diverso. Systemd-appd crea un punto unico di verità.
Mark
Quindi è una questione di coerenza, non di sicurezza?
Mimi
Entrambe. Coerenza rende la sicurezza più facile da implementare e verificare.
O Pulso
- Ogni componente del desktop Linux — sandbox, PipeWire, portali, compositor Wayland — ricostruisce l'identità di un'app a modo proprio, generando incoerenze pericolose nella gestione dei permessi.
- Il problema si aggrava perché un'applicazione moderna non è un singolo processo: genera figli, usa helper, viene lanciata da launcher, rendendo instabile qualsiasi identificazione basata su PID o nome dell'eseguibile.
- Adrian Vovk ha pubblicato una pull request nel repository di systemd con una prima implementazione funzionante di systemd-appd, nato dalle discussioni su Flatpak-Next avviate con Sebastian Wick nel 2025.
- Il servizio sfrutta le unità utente e i cgroup di systemd per legare ogni istanza applicativa attiva a un'identità stabile e a un insieme di permessi interrogabile da qualsiasi componente del desktop.
- Il codice è ancora in fase di revisione e potrebbe cambiare significativamente, ma la direzione è chiara: un'infrastruttura comune per l'identità delle app, non legata solo a Flatpak ma potenzialmente aperta a qualsiasi programma integrato con le convenzioni di sessione di systemd.
Sul desktop Linux, sapere con certezza quale applicazione si cela dietro un processo è da sempre una questione aperta — e da quella questione dipende chi può accedere alla videocamera, al microfono, alle risorse più sensibili. Adrian Vovk ha proposto systemd-appd, un nuovo componente di systemd che ambisce a diventare il punto di riferimento condiviso per l'identità delle applicazioni e i loro permessi, mettendo fine alla frammentazione tra sandbox, D-Bus, PipeWire e portali. Il codice è ancora in revisione, ma l'idea tocca qualcosa di fondamentale: la coerenza tra ciò che un sistema sa di un programma e ciò che quel programma è autorizzato a fare.
Identificare con certezza quale applicazione corrisponda a un determinato processo è sempre stato un problema irrisolto sul desktop Linux — e la posta in gioco è alta, perché da quella risposta dipende se un programma possa accedere alla videocamera, al microfono o ad altre risorse protette. Adrian Vovk ha proposto systemd-appd, un nuovo componente di systemd pensato per centralizzare in un unico servizio sia l'identità delle applicazioni in esecuzione sia i loro permessi associati.
L'idea matura da discussioni avviate nel 2025 tra Vovk e Sebastian Wick mentre lavoravano al futuro di Flatpak. A ottobre 2026 la proposta ha assunto forma concreta con una pull request nel repository di systemd. Il codice è ancora in revisione e non è integrato nelle distribuzioni attuali.
Il nodo del problema è che un'applicazione non coincide con un singolo processo: può generare figli, usare helper o essere lanciata da launcher che eseguono una chiamata exec(). Affidarsi al PID o al nome dell'eseguibile non garantisce un'identità stabile. Oggi sandbox, D-Bus, PipeWire, portali e compositor ricostruiscono ciascuno l'identità di un programma a modo proprio, con incoerenze che complicano la gestione dei permessi.
Systemd-appd sfrutta una struttura già esistente: i processi delle applicazioni possono vivere dentro specifiche unità utente e nei relativi cgroup, seguendo convenzioni precise per i nomi delle unità. Quando un'app si registra, il servizio verifica che il processo appartenga a un'unità conforme e lega quell'identità all'istanza attiva. Il risultato è un punto comune da interrogare: PipeWire, i portali e il compositor possono sapere in modo coerente quale app sta richiedendo accesso a una risorsa e quali permessi possiede in quel momento.
Il progetto non è un registro dei software installati né un nuovo package manager: tiene traccia delle istanze applicative attive e delle informazioni necessarie ai servizi che decidono sui permessi. Non è nemmeno limitato a Flatpak — in prospettiva può servire a qualsiasi programma integrato con le convenzioni di sessione di systemd. Prima di arrivare nelle distribuzioni, però, systemd-appd potrebbe cambiare ancora significativamente.
Su un desktop Linux, identificare con certezza quale applicazione corrisponda a un determinato processo è sempre stato un problema irrisolto. La questione diventa critica nel momento in cui quella risposta deve decidere se un programma possa accedere alla videocamera, al microfono o a altre risorse protette. Adrian Vovk ha proposto systemd-appd, un nuovo componente di systemd progettato per centralizzare in un unico servizio sia l'identità delle applicazioni in esecuzione sia i loro permessi associati.
L'idea non è nata dal nulla. Nel 2025, Sebastian Wick e Adrian Vovk stavano già discutendo di questo problema mentre lavoravano al futuro di Flatpak e a quello che internamente veniva chiamato Flatpak-Next. A ottobre 2026, la proposta ha assunto una forma concreta: Vovk ha pubblicato una pull request nel repository di systemd con una prima implementazione funzionante. Il codice è ancora in fase di revisione e non rappresenta una funzione già integrata nelle distribuzioni Linux attuali.
Il problema che systemd-appd cerca di risolvere è fondamentale per come funziona un desktop moderno. Un'applicazione non corrisponde necessariamente a un singolo processo: può generare processi figli, usare helper, avviare componenti attraverso altri servizi o essere lanciata da launcher che eseguono una chiamata exec(). Basarsi solo sul PID, sul nome dell'eseguibile o sul percorso del file non garantisce un'identità applicativa stabile. Oggi, ogni componente del desktop—sandbox, servizi D-Bus, PipeWire, portali, compositor Wayland—ricostruisce l'identità di un programma a modo proprio. Questo frammentarsi crea incoerenze e complica la gestione dei permessi.
Systemd dispone già di una struttura adatta allo scopo: i processi delle applicazioni possono vivere dentro specifiche unità utente e nei relativi cgroup. La documentazione sull'integrazione con i desktop environment prevede una convenzione precisa per i nomi delle unità applicative. Systemd-appd sfrutta esattamente questa regola. Quando un'app si registra, il servizio verifica che il processo appartenga a un'unità conforme allo schema e lega quell'identità all'istanza attiva. Il vantaggio principale è la creazione di un'identità condivisa. Se un software tenta di aprire la videocamera, usare il microfono o raggiungere una risorsa protetta, il componente incaricato di autorizzare l'operazione può risalire in modo più affidabile all'app che ha fatto la richiesta.
Oggi PipeWire, D-Bus, i portali desktop e il compositor non vedono necessariamente il programma nello stesso modo. La gestione si complica ulteriormente quando entrano in gioco sandbox e permessi dinamici. Systemd-appd offre invece un punto comune da interrogare: è in grado di rispondere che una richiesta arriva da una certa app e che quella app possiede determinati permessi in quel momento. PipeWire continuerà a controllare l'accesso ai flussi audio e video, ma riceverà informazioni molto più coerenti su chi sta chiedendo di usarli.
Il progetto nasce dalle discussioni su Flatpak-Next, dove riconoscere meglio le applicazioni può semplificare sandboxing, portali e gestione delle autorizzazioni. Il meccanismo proposto però non è legato alle sole app Flatpak. In prospettiva può servire a qualsiasi programma integrato con le convenzioni previste da systemd per la sessione desktop. Anziché aggiungere un ulteriore strato specifico, systemd-appd prova a offrire un'infrastruttura utilizzabile da più componenti del desktop Linux. Non si tratta di un registro dei software installati né di un nuovo package manager. Lo strumento non ha il compito di elencare i pacchetti RPM, DEB, Flatpak o Snap presenti sul computer. Tiene piuttosto traccia delle istanze applicative attive, della loro identità e delle informazioni che servono ai servizi chiamati a decidere sui permessi.
Il tema riguarda aspetti sempre più rilevanti per chi usa Linux ogni giorno: l'accesso a videocamera e microfono, l'isolamento delle app e la gestione granulare delle autorizzazioni. L'obiettivo è collegare due informazioni che oggi restano separate—quali processi girano sul sistema e quale applicazione rappresentano, insieme a ciò che quell'applicazione è autorizzata a fare. Essendo ancora in revisione, systemd-appd potrebbe cambiare significativamente prima di arrivare nelle distribuzioni.
Citações Notáveis
Un desktop moderno è fatto di sandbox, servizi D-Bus, PipeWire, portali e compositor Wayland, e ognuno di questi pezzi oggi ricostruisce l'identità di un programma a modo suo— Dalla proposta di systemd-appd
Quer a matéria completa?
Leia o original em TecnoAndroid ↗
War & Conflict