Introduzione

Uno dei fattori chiave per la sicurezza di un sistema è il controllo dei permessi di accesso. Permette ai proprietari di file di porre dei limiti agli utenti che possono leggere, scrivere, ed eseguire o cambiare file, eseguire processi ("compiti") e ad altre parti del sistema.

Linux, come ogni SO simil-UNIX, ha un sistema incorporato di controllo dei permessi dei file. Assegna gli attributi seguenti ad ogni file nel suo file system:

Si può vedere il proprio utente e gruppo eseguendo  id -a  in una shell.

Se uno dei gruppi di un utente ha un particolare permesso di accesso, allora anche l'utente ha tale permesso.

L'ID di gruppo effettivo (considerato quando vengono creati file e directory, come spiegato più avanti) è impostato, nella maggior parte dei casi, all'ID di gruppo primario

Pagina in corso di rifacimento dopo questo punto

Termini usati:

file system - una struttura su disco che contiene la descrizione dei file (come gli attributi menzionati più sopra, la data di modifica dei file, ecc.) e il contenuto stesso dei file. I file system sono contenuti in partizioni sul disco (chiamate anche fette). Alcuni dei file system più popolari oggigiorno sono ext4, xfs e btrfs. Se si usa Debian, probabilmente si usa ext4. È bene menzionare il fatto che le directory ('cartelle') sono anch'esse considerate file, che semplicemente contengono altri file. Perciò i permessi si applicano anche alle directory.

gruppo utente - nei sistemi simil-UNIX, ogni utente viene assegnato ad un qualche gruppo. Gli utenti nello stesso gruppo possono condividere diritti, per esempio i permessi di un file possono essere impostati in modo che tutti gli utenti di un gruppo possano modificare i suoi contenuti.

Sezione 2: I permessi UNIX spiegati

Una volta imparata la teoria, è bene passare alla pratica: che aspetto hanno i permessi UNIX e come usarli? Prima di tutto, si esaminino i permessi di un file di esempio. Eseguendo il comando seguente in una console o un emulatore di terminale Linux: 

stat /etc/hostname

si vede un elenco degli attributi del file che include il tipo di file (potrebbe anche essere una directory, un collegamento simbolico, ecc.), la dimensione del file, ecc. ed una riga come quella sottostante che è quella interessante in questo caso: 

Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)

Questo file appartiene all'utente root (l'amministratore di sistema) e al gruppo root. Prima della barra inclinata sono mostrati gli ID utente numerici: questo è il modo in cui sono archiviati nel file system. I nomi dell'utente e dei gruppi vengono recuperati cercando gli ID numerici nei database password e group.

Il campo Access contiene un numero ottale e la sua rappresentazione in forma leggibile (anche se alcuni considerano la forma numerica più leggibile). È fondamentale sapere cosa significhi il numero dei permessi. È formato da quattro cifre, comprese tra 0 e 7. Per il momento la prima non viene presa in considerazione e vengono analizzate le ultime tre dato che sono quelle usate più comunemente su tutti i sistemi. Nell'esempio, queste cifre sono 644. Ogni cifra può essere la somma di 4, 2 e 1, ma non tutte le componenti devono essere incluse il che risulta in un possibile valore compreso tra 0 e 7. Di seguito sono elencati i significati di ciascuna componente della somma, con "soggetto" che rappresenta l'utente, il gruppo o gli altri, come spiegato in seguito.

Il numero 5, perciò, significa: permesso di leggere ed eseguire, ma non di scrivere.

Le cifre definiscono rispettivamente i permessi per il proprietario, il gruppo e tutti gli altri. Per tanto si può vedere che nell'esempio precedente, il proprietario del file (root) può scrivere nel file e leggere il suo contenuto, mentre il gruppo 'root' e gli altri utenti (che non sono root, né fanno parte del gruppo 'root') hanno il permesso di leggere il file.
Ora, si confrontino questi permessi con quelli del file /etc/shadow (usando nuovamente "stat"). Questo file ha 0 come terza cifra significativa, perciò gli utenti che non sono root né appartengono al gruppo "shadow" non possono nemmeno leggere il file. Si può facilmente verificarlo avviando un editor di testo e cercando di aprire /etc/shadow: come utente regolare non si dovrebbe essere in grado di vedere il suo contenuto dato che contiene le password a livello di sistema (e questo esula dallo scopo di questo piccolo ?HowTo).

Forma leggibile

Diversi strumenti di sistema e programmi grafici abbracciano l'idea di una forma leggibile: una stringa di 10 caratteri consecutivi. Per vederne un esempio, eseguire il comando seguente: 

ls -l /etc

L'opzione -l dice a "ls" di visualizzare i permessi dei file nella colonna a sinistra dell'output. La sequenza completa che si può ottenere è simile alla seguente (anche se probabilmente non si troverà un file così in /etc): 

-rwxrwxrwx+

Ora si suddivida questo in tre parti; il primo carattere definisce il tipo di nodo, che è - per i file normali, d per le directory, l per i collegamenti simbolici, c per i device a caratteri, p per i pseudo-terminali and b per i device a blocchi. I file, le directory e i collegamenti si trovano comunemente in tutto il file system, mentre i device e i pseudo-terminali dovrebbero essere presenti solo in /dev. Si hanno perciò 3 pezzi, ciascuno di 3 caratteri: rwx rwx rwx. Corrispondono esattamente alle rispettive cifre dei permessi: se un permesso è abilitato è presente una lettera, altrimenti è presente - al posto della lettera. In questo caso, il primo rwx corrisponde a 7 per il proprietario, il secondo è ancora 7 per il gruppo proprietario e il terzo corrisponde ai permessi per tutti gli altri (il "mondo"). Perciò, per esempio, 640 si traduce in: 

rw-r-----

(rw- per il proprietario, r-- per il gruppo, --- per gli altri). L'ultima colonna contiene il segno +. È improbabile vederlo quando si elenca il contenuto di una directory (la colonna appare vuota), ma significa che sono attive regole estese per gli accessi, perciò i reali permessi del file non sono solamente quelli mostrati dalla modalità di accesso del file: si possono leggere informazioni su ACL più avanti in questo documento.

Una nota sulla gestione dei percorsi

Per accedere ad un qualunque percorso nel file system, l'utente (con cui viene eseguito un particolare processo) deve avere come minimo i permessi di esecuzione per tutte le directory genitrici. Perciò, se si tenta di accedere ad un file di esempio /etc/security/limits.conf, anche se questo ha una modalità 0755 (sempre nell'esempio ipotetico), non è necessariamente vero che si è liberi di leggerlo. Per leggere il file, si deve essere in grado di "eseguire" tutte le sue directory genitrici, perciò si devono avere i permessi di esecuzione per /etc e /etc/security. Se o /etc o /etc/security ha impostati dei permessi che non permettono di eseguirla (1), allora la lettura di /etc/security/limits.conf fallisce. Questa regola si applica a tutto il file system.

Impostazioni predefinite per file e directory nuovi

Questa sezione è presente principalmente per fornire materiale di riferimento e per aiutare nella comprensione. I permessi e l'assegnazione ad un gruppo predefiniti spesso non vengono modificati perciò si può saltare questa sezione e tornare a leggerla in seguito per avere ulteriori dettagli in caso di bisogno.

I permessi associati con i file e le directory appena creati sono, per la maggior parte, determinati da una cosa chiamata umask. Questa è un numero ottale di 3 cifre spesso fatto precedere da uno 0 in più per rendere chiaro che si tratta di un numero in base 8. Il valore viene sottratto da 0777 per ottenere i permessi associati ai nuovi oggetti creati nel file system. L'umask di un sistema Debian "standard" è 0002 o 0022 (a seconda del fatto che siano configurati gli gruppi privati degli utenti). Per esempio 0022 fa sì che i permessi predefiniti siano 0755, cioè il proprietario ha tutti i permessi, il gruppo ha permessi di lettura ed esecuzione ma non di scrittura e tutti gli altri possono leggere ed eseguire ma non scrivere. Ci si potrebbe aspettare che tutti i nuovi file siano creati come eseguibili, ma ciò non avviene perché la chiamata di sistema che crea i file lo fa in modo predefinito come non eseguibili. Le directory invece hanno il bit di esecuzione impostato, se l'umask lo permette, e perciò possono essere, in modo predefinito, attraversate da tutti.

Il comando di shell umask può essere usato per visualizzare (senza argomenti) l'attuale umask o per cambiare il suo valore; vedere bash-builtins(7) § umask. 

$ umask
0022
$ (umask 0077; touch private.log)
$ echo 'default' >default.log
$ ls -l
total 4
-rw-r--r-- 1 test test 8 Jul 30 10:24 default.log
-rw------- 1 test test 0 Jul 30 10:24 private.log

I processi generati ereditano il valore di umask dal genitore e possono cambiarlo usando la chiamata di sistema umask(2). Vedere la sezione Impostare l'umask predefinita più avanti per come configurare l'umask predefinita.

L'UID (numero ID utente) utente associato con un file o directory appena crati è quello effettivo del processo in esecuzione. Nella maggior parte dei casi queso è l'uid dell'utente che ha fatto il login e avviato il processo.

Il gruppo associato ad un file o directory appena creati è il gruppo "effettivo" del processo in esecuzione. Questo è solitamente il gruppo chiamato come il nome utente dell'utente che ha fatto il login, ma può essere manulmente modificato (insieme al gruppo "reale") per ciascun processo con il comando newgrp anche se ciò viene fatto di rado.

La prima delle 4 cifre ottali che rappresentano i permessi contiene i bit setuid e setgid. Queti possono essere usati per sovrascrivere alcune delle impostazioni predefinite descritte sopra, ma non è il caso di entrare nei dettagli tranne per far notare che l'idioma per progetti collaborativi gruppi privati degli utenti (vedere in seguito) dipende dal comportamento del bit setgid.

Sezione 3: Modificare i permessi dei file

Questa sezione mostra, usando un esempio, l'uso base del comando chmod. Chmod è uno dei migliori amici dell'amministratore di sistema ed è lo strumento standard per manipolare i permessi dei file in vari *nix (funziona anche in *BSD e Solaris!). Prima di tutto, creare un file a scopo dimostrativo; in questo esempio viene usato il nome testfile. I comandi che seguono vengono eseguiti in un emulatore di terminale o in una console Linux. Fondamentalmente si può semplicemente farne il copia&incolla e vedere come funzionano. 

# prima di tutto, creare il file usando il comando touch (vedere "man touch" per i dettagli)
touch testfile
# ora, vedere i suoi permessi
stat testfile
# modificare il file in modo che i membri del gruppo e gli altri utenti possano scriverlo
chmod 666 testfile
# vedere i nuovi permessi
stat testfile

Esiste un caso speciale: per pulire i bit speciali con directory, si devono indicare i bit della modalità dei file esplicitamente (in modalità simbolica) o come modalità numerica per operatore (in descrizione ottale) (vedere ulteriori informazioni in: 'info coreutils, sezione 27.5 "Directories and the Set-User-ID and Set-Group-ID Bits").

I permessi sono cambiati? Si può verificare se il comando ha veramente funzionato iniziando una nuova sessione facendo il login con un altro account utente, o usando il comando su nome_utente. Se si ha un solo account utente, crearne uno nuovo a scopo di test: 

su
(inserire la password di root, per fare il login all'account root e aggiungere un utente di test)
adduser demo
# si può rimuovere questo utente una volta che si è finito usando: deluser demo

Ora, fare il login in demo, aprire testfile (nella directory home del proprio utente regolare) e digitarvi qualcosa. Salvare e poi controllare con il proprio account utente che nel contenuto ci sia qualsiasi cosa si è scritta. Voila! Si può ora voler controllare i vari permessi diversi. Provare ad usare chmod con argomenti come 644, 640 e così via.

Sezione 4: Esempi di scenari che chiamano in causa chmod

Si sa ora come cambiare i permessi dei file. Tuttavia come può essere utile farlo nella vita reale, a parte lasciare che i propri amici lascino un messaggio a caso nei propri file di testo?

Caso 1: Foto di famiglia

Situazione: Le foto di famiglia sono memorizzate nella directory Foto del proprio account utente. Altri membri della famiglia usano il computer e si vuole che siano in grado di accedere alle foto.

Domanda: Come impostare i permessi della directory affinché gli altri utenti possano vedere i propri file ed il loro contenuto?

Risposta: Impostare i permessi della directory a 755 e quelli dei file in essa contenuti a 644: 

chmod 755 Foto
# Foto/* significa tutti i file nella directory Foto
chmod 0644 Foto/*

Caso 2: Software e file dati per il proprio dipartimento al lavoro

Situazione: Nella propria directory home c'è un programma ~/AppSoftware/programma.bin. Esso memorizza i file dati specifici per il proprio dipartimento in ~/NostriDati. L'amministratore di sistema ha assegnato a tutte le persone del proprio dipartimento il gruppo utente "miodipart". Si desidera che le altre persone del proprio dipartimento possano eseguire il software fornito e scrivere i file dati. Allo stesso tempo, ad altre persone al di fuori del gruppo dovrebbe essere permesso eseguire il software ma non modificare i dati. Per ragioni di semplicità non viene considerata la registrazione di chi ha aggiunto/rimosso dati (mantenere un registro è una necessità nella vita reale), ma solo l'attribuzione di permessi appropriati.

Domanda: Come permettere l'accesso in esecuzione per un gruppo ad un file (programma binario) e l'accesso in lettura-scrittura ad un'altra directory per lo stesso gruppo, negandolo allo stesso tempo agli altri utenti (mondo)?

Risposta: Per l'esempio nella situazione descritta, ciò si può ottenere con: 

# qui di seguito: l'opzione -R ha effetto sulla directory e sui file/sottodirectory in essa
chmod -R 0755 ~/AppSoftware
chmod -R 0770 ~/NostriDati

Nel caso che i file abbiano l'attributo di gruppo impostato in modo sbagliato, si può correggerlo eseguendo come prima cosa chgrp -R miodipart file, dove "miodipart" è il nome del gruppo, "file" è il percorso dei file e l'opzione -R dice a chgrp di fare un'esecuzione ricorsiva (vedere l'esempio di codice precedente). Chgrp cambia il gruppo dei file in quello specificato.

Caso 3: File classificati

Domanda: Come proteggere file che devono rimanere segreti?

Risposta: Una protezione molto di base può essere ottenuta cambiando con chmod i permessi dei file/directory delicati in 0600. Tuttavia si tenga a mente che l'amministratore di sistema (root) può ancora accedervi, indipendentemente dai permessi dei file. Perciò, a parte bloccare i permessi dei file, è caldamente consigliabile cifrare i file usando un software di cifratura robusto (provare la cifratura OpenPGP attraverso programmi come KGpg o vedere ccrypt: cifratura simmetrica).

Scenari di condivisione di gruppo di file ed i limiti dei permessi base UNIX

Gli esempi descritti in precedenza mostrano l'utilità dei permessi UNIX per i file. Si può accordare l'accesso ai propri file agli utenti del proprio gruppo, lasciare che i file siano visibili da tutti oppure mantenerli solo per sé stessi. Tuttavia esistono situazioni in cui questo modello di controllo degli accessi non è sufficiente.

Si ipotizzi di essere in un grosso sistema (un server, per esempio) e di fare parte, insieme a diverse dozzine di altri utenti, del gruppo "utenti". Ora, se si vogliono rendere disponibili alcuni dei propri file a un solo utente, senza che gli altri possano leggerlo, come possono essere utili i permessi UNIX? Si può in questo caso usare l'idioma per gruppi privati degli utenti per la condivisione di directory: una soluzione frequente per questo problema. Ma tale idioma spinge il sistema dei permessi UNIX al suo limite e ci sono casi, compresi casi di semplice condivisione di file tra 2 persone, in cui l'idioma è semplicemente non adatto.

Quando si raggiunge il limite dei permessi base UNIX per i file è arrivato il momento di usare...

ACL: elenchi di controllo degli accessi in Linux

ACL (Access Control Lists, elenchi di controlli degli accessi) sono un mezzo esteso per definire i diritti di accesso per i file e per oggetti. Permettono di specificare i permessi dei file in una maniera più dettagliata, assegnando a ciascun utente o gruppo (in aggiunta al proprietario e al gruppo impostati per il file) privilegi diversi. Per esempio, si può condividere un file solamente con uno specifico utente, indipendentemente dai gruppi a cui appartiene.

Come utilizzare questa nuova, potente funzionalità?

Per prima cosa, assicurarsi che il proprio sistema abbia il supporto per ACL. Prima di poter abilitare l'ACL per i propri file devono essere soddisfatti diversi requisiti. Controllare la versione del proprio kernel. Se è successiva a 2.6.18, allora è probabile che si abbia già internamente il supporto ACL. (Non sono sicurissimo sulla versione a partire dalla quale i kernel Debian abbiano ricevuto la patch per ACL). Il passo successivo è il pacchetto acl, necessario per la manipolazione degli attributi ACL. Lo si può installare con il comando: 

 # se non si è fatto il login come root, usare prima "su"
apt-get install acl

In alternativa si può usare il gestore di pacchetti Synaptic, o un altro gestore di pacchetti, per scaricare ed installare il pacchetto. Se non si è l'amministratore di sistema, chiedere al proprio amministratore di abilitare l'ACL sulla macchina.
Una volta che acl è installato, si può provare a vedere se il proprio file system lo supporta. Un comando d'esempio è (assumendo che il file "testfile" esista): 

setfacl --modify user:demo:5 testfile

Se setfacl si lamenta di un errore, probabilmente è necessario montare il proprio file system con l'opzione acl. Assumendo che il file "testfile" sia localizzato nel file system / , eseguire il comando seguente come root: 

mount -o remount,acl /

Provare di nuovo setfacl. Se viene eseguito con successo, l'invocazione di: 

getfacl testfile

dovrebbe mostrare, tra le altre cose, una riga come questa:

user:demo:r-x

Qui, rx significa permessi di "lettura e esecuzione", che sono equivalenti a 5. Per vedere se l'ACL funziona, impostare i permessi del file "testfile" a 700 usando chmod e cercare di aprirlo dall'account utente "demo". Se lo si può fare, l'ACL ha di fatto aggirato i permessi UNIX. Il proprio file system è ora pronto per un controllo granulare degli accessi con ACL!

Nota: per abilitare l'ACL in modo permanente per alcuni file system, si dovrebbe includere l'opzione acl in /etc/fstab. Fare riferimento alla pagina di manuale fstab(5) per istruzioni a riguardo.

Esempi di utilizzo di setfacl per gestire i permessi dei file 

setfacl -R -m user:mario:6 filedir   # imposta permessi di lettura-scrittura per mario su filedir e tutto il suo contenuto
setfacl -m group:amministr-sist-junior:4 /var/log/apache2/error.log    # permette ai membri del gruppo amministr-sist-junior di leggere il file di registro degli errori di Apache2
setfacl -m user:cattivodavide:0 miei_appunti.txt    # impedisce all'utente cattivodavide di accedere a miei_appunti.txt

ACL predefiniti (ereditati)

Nota: un bug nei comandi cp e mv di coreutils limita la portata di quanto spiegato qui sotto alla semplice creazione di file, ad esempio con touch; con la copia e lo spostamento, la "maschera predefinita" della directory genitrice obiettivo non verrà ereditata come "maschera di accesso" per il file o la directory copiati o spostati: http://debbugs.gnu.org/db/85/8527.html

Gli ACL predefiniti sono uno strumento preziosissimo quando si crea una directory che si vuole condividere in lettura o scrittura tra diversi utenti. Questo suggerimento è stato ispirato da una discussione nel forum Debian: http://forums.debian.net/viewtopic.php?f=10&t=53591

Gli ACL predefiniti sono voci di controllo degli accessi che vengono ereditate da tutti i sotto-elementi di una directory (è permessa l'azione ricorsiva in profondità!). Perciò, se si vuole creare una directory per mario e giovanni in modo che entrambi possano lavorare sui file dell'altro, dovrebbero essere sufficienti i comandi elencati in seguito (notare l'opzione -d per setfacl che imposta un ACL predefinito): 

mkdir spazio_comune
setfacl -m u:mario:7 spazio_comune
setfacl -d -m u:mario:7 spazio_comune
setfacl -m u:giovanni:7 spazio_comune
setfacl -d -m u:giovanni:7 spazio_comune

Nota all'esempio precedente: un ACL predefinito viene ereditato da tutti i nodi figli come voce ACL e come ACL predefinito, ma un ACL predefinito di per sé non comporta alcuna azione relativa ai permessi: da qui la necessità di comandi doppi. Il primo comando dà all'utente "mario" il permesso di scrittura, lettura ed esecuzione per la directory, e il secondo imposta l'ACL predefinito che verrà ereditato.

Ora, ogni volta che viene creato un file, esso mantiene proprietario e gruppo originali, ma ad esso dovrebbero essere automaticamente assegnati gli ACL definiti in precedenza. Questo è utile, ad esempio, quando si hanno utenti che collaborano allo sviluppo di un sito web. Si può usare Apache o PHP in esecuzione come www-data, scrivere uno script per cambiare, al momento della creazione, il proprietario del file in www-data (inotify è di aiuto!), e tutti i file continuano ad essere scrivibili da mario e giovanni, gli sviluppatori Web.

Appendice: alcuni suggerimenti

  adduser io altroutente # aggiunge l'utente "io" al gruppo "altroutente"

In seguito "altroutente" deve semplicemente impostare i propri file a 0750 o qualsiasi altra impostazione di permessi desideri. Questa è, tuttavia, la vecchia maniera di affrontare i permessi granulari per i file e dovrebbe essere, quando possibile, evitata usando piuttosto i gruppi privati degli utenti o ACL.

Questo è tutto! Buon divertimento e grazie dell'ascolto.

Impostare l'umask predefinita

https://www.debian.org/doc/manuals/securing-debian-manual/ch04s11.en.html#idm1514 - Impostare le umask degli utenti in Securing Debian Manual

L'umask ha un effetto sui permessi dei nuovi file e directory. Esempi di valori comunemente usati:

Citando /etc/login.defs: "Non esiste una sola risposta: ogni amministratore di sistema deve prendere la propria decisione". Si possono trovare alcuni collegamenti a discussioni in Debate/umask.

Impostare l'umask è per certi aspetti simile a configurare Variabili d'ambiente e aggiungere umask 077 a ~/.profile o ~/.bashrc può non essere sufficiente nonostante si possa trovare questo suggerimento in molte guide. In passato l'umask per tutti gli utenti era impostata nel file /etc/profile, ma ciò è stato cambiato nel 2010 (#583967), perciò usare invece PAM.

Configurazione di umask a livello di sistema

Fare attenzione se si decide di cambiare il valore predefinito di umask. Valori restrittivi possono rendere file e directory non leggibili o scrivibili da utenti che dovrebbero avere l'accesso. Il risultato peggiore è avere applicazioni che non funzionano che non possono leggere i file di configurazione. Il caso opposto è il bit di scrittura da parte del gruppo non reimpostato combinato con un gruppo predefinito sbagliato.

A partire da Debian 12 Bookworm le directory home per gli utenti sono create in modo predefinito con i permessi 0700, perciò la maggior parte dei file degli utenti è protetta, nonostante l'umask predefinita permissiva. I permessi delle directory create in precedenza possono essere cambiati in modo simile. Come alternativa ad umask non è ideale. I file creati in /tmp non sono protetti a meno che ogni applicazione non imposti esplicitamente umask o permessi. In alcuni casi la directory home deve essere attraversabile per gli altri utenti. Esempi sono ~/public_html per Apache e contenitori LXC non privilegiati. Soluzioni possibili sono le liste di controllo degli accessi o il bit come eseguibile da tutti senza quello di lettura per la directory home.

L'umask a livello di sistema è configurato nel file /etc/login.defs. Leggere i commenti lì e login.defs(5). 

UMASK           077

In Debian 12 Bookworm e rilasci precedenti, pam_umask(8) manca nella configurazione di PAM. Come risultato, il valore specificato in etc/login.defs non viene applicato. Per questo motivo l'umask non è reimpostata quanto un utente esegue ad esempio su - per eseguire un qualche comando come amministratore. Questo gruppo di bug è risolto in Trixie (Vedere ad es.. 583958).

Per risolvere in locale, controllare che i file /etc/pam.d/common-session e /etc/pam.d/common-session-noninteractive contengano 

session optional pam_umask.so usergroups

e altrimenti aggiungere tale riga. In Trixie può essere omesso usergroups, è il valore predefinito impostato attraverso un'opzione di compilazione.

Considerare l'impostazione anche di HOME_MODE in /etc/login.defs dato che altrimenti UMASK ha effetto sui permessi per le directory home crate da useradd(8). In Debian tuttavia lo strumento raccomandato è adduser(8) che ignora login.defs e legge invece adduser.conf(5). (Con le impstazioni predefinite adduser e adduser creano directory home con permessi diversi.)

Impostazione di umask per singoli utenti

A seconda del tipo di login e del modo in cui è stato avviato un particolare processo possono essere vere le seguenti opzioni:

Tenere a mente che il valore di umask può essere preservato da su e sudo, a meno che non sia abilitato pam_umask, vedere Configurazione di umask a livello di sistema.

Per i processi avviati attraverso la sessione utente di sistema, l'amministratore di sistema può creare file override per UID specifici, ad es. /etc/systemd/system/user@1000.service.d/umask.conf (fonte) 

[Service]
UMask=0007

ed eseguire 

systemctl daemon-reload

Un utente che non può modificare i file di sistema può mettere lo stesso file in ~/.config/systemd/user/service.d/ e verrà applicato a tutti i servizi nella sua sessione utente; vedere systemd.unit(5) § EXAMPLES. È necessario fare il log out e di nuovo il login per far sì che la modifica abbia effetto. Non è sufficiente usare systemctl --user daemon-reload, deve anche essere riavviato il lanciatore delle applicazioni in esecuzione. Usare UMask=0077 se l'utente non ha un proprio gruppo utente privato.

Vedere anche

CategoryCommandLineInterface | CategorySystemSecurity | CategorySystemAdministration | ?CategoryUserManagement