In genere, ogni utente fisico su un sistema ha un ID e un processo in esecuzione viene eseguito come l'utente che lo avvia. Ciò significa che il processo è in grado di accedere a tutti i file dell'utente, anche a quelli non destinati a questo specifico programma. Ad esempio, se inizi a eseguire Firefox, questo ha accesso ai file di configurazione di Chrome e viceversa. Ma come puoi vedere questo è irrazionale perché qualsiasi browser funziona correttamente senza accedere ai file di configurazione di un altro.
Questo è anche pericoloso se si considera che un programma dannoso avviato dall'utente è sufficiente per modificare furtivamente tutti i file dell'utente, oltre a inviare e-mail ad altre persone come utente, accedere agli account Web se l'utente memorizza un cookie e molti altri possibili comportamenti indesiderati. La causa principale è che il processo è in esecuzione come utente, non come se stesso.
Il problema è stato parzialmente risolto nei sistemi Linux di commodity specificando UID e GID all'avvio di un processo. Mentre questo è vero per molti demoni di sistema, non è il caso tipico dei software client. Molte utilità come brower, client FTP, editor di testo vengono eseguite come utente ma non come il proprio UID.
Il sistema operativo che cerca una soluzione a livello di sistema operativo è Android, in cui ogni app ha il proprio ID e accede ai dati dell'utente tramite autorizzazioni. Aggiunge una certa complessità ma impedisce molte possibilità di attacco. Se ciò è considerato una buona pratica, allora perché questa funzione non viene trasferita su Linux desktop (o ce l'ha)? Con una distribuzione più ampia di systemd , gli utenti ora dispongono di un controllo molto migliore dei processi corrono e non ci dovrebbero essere difficoltà tecniche nell'implementazione di tale funzione.