9.3. Gestione dei permessi

Linux è decisamente un sistema multi-utente, per cui è necessario fornire un sistema di permessi per il controllo delle operazioni autorizzate su file e directory, che comprende tutte le risorse di sistema e i device (in un sistema Unix, qualsiasi dispositivo è rappresentato da un file o directory). Questo principio è comune a tutti i sistemi Unix, ma un promemoria è sempre utile, soprattutto perché ci sono alcuni utilizzi avanzati interessanti e relativamente sconosciuti.

9.3.1. Owners and Permissions

Ogni file o directory ha permessi specifici per tre categorie di utenti:

il proprietario (simboleggiato dalla lettera u di «user»);
il gruppo proprietario (simboleggiato dalla lettera g di «group»), in rappresentanza di tutti i membri del gruppo;
gli altri (simboleggiati dalla lettera o di «other»).

Three basic types of rights can be combined:

lettura (simboleggiata dalla lettera r di «read»);
scrittura (o modifica, simboleggiata dalla lettera w di «write»);
esecuzione (simboleggiata dalla lettera x come in «eXecute»).

Nel caso di un file, questi diritti sono di facile comprensione: l'accesso in lettura permette di leggerne il contenuto (incluso farne una copia), l'accesso in scrittura permette di cambiarlo, e l'accesso in esecuzione permette di eseguirlo (che funziona solo se si tratta di un programma).

SICUREZZA eseguibili setuid e setgid

Two particular rights are relevant to executable files: setuid and setgid (symbolized with the letter “s”). Note that we frequently speak of “bit”, since each of these Boolean values can be represented by a 0 or a 1. These two rights allow any user to execute the program with the rights of its owner or its group, respectively. This mechanism grants access to features requiring higher level permissions than those you would usually have.

Poiché un programma con setuid root è sistematicamente eseguito con l'identità del superutente, è molto importante assicurarsi che sia sicuro e affidabile. Infatti, un utente che riuscisse a sovvertirlo per invocare un comando di sua scelta potrebbe poi impersonare l'utente root ed avere tutti i diritti sul sistema.

If you require running a program under a different user or if a program requires higher permissions, the sudo, su, or runuser commands are usually better choices than using these bits (see Sezione 8.9.4, «Condivisione dei privilegi di amministrazione»).

Una directory è gestita in modo diverso. L'accesso in lettura dà il diritto di consultare l'elenco delle sue voci (file e directory), l'accesso in scrittura permette di creare o eliminare file, mentre l'accesso in esecuzione permette di attraversarla (soprattutto di andarvi con il comando cd). Essere in grado di attraversare una directory senza essere in grado di leggerla dà il permesso di accedere alle voci al suo interno di cui si conosce il nome, ma non di trovarle senza sapere che esistono o sotto quale nome esatto.

SICUREZZA directory setgid e sticky bit

Il bit setgid vale anche per le directory. Qualsiasi elemento appena creato in tali directory viene assegnato automaticamente al gruppo proprietario della directory genitore, invece di ereditare il gruppo principale del creatore come al solito. Questa configurazione evita che l'utente debba cambiare il suo gruppo principale (con il comando newgrp) quando lavora in un albero di file condiviso tra più utenti dello stesso gruppo dedicato.

Lo «sticky» bit (simboleggiato dalla lettera «t») è un permesso che è utile solo nelle directory. È particolarmente utilizzato per le directory temporanee in cui tutti hanno accesso in scrittura (come /tmp/): esso limita l'eliminazione di file in modo che solo il loro proprietario (o il proprietario della directory genitore) possa farlo. In mancanza di questo, tutti potrebbero eliminare i file di altri utenti in /tmp/.

Tre comandi controllano i permessi associati ad un file:

chown utente file cambia il proprietario del file;
chgrp gruppo file cambia il gruppo proprietario;
chmod permessi file cambia i permessi per il file.

Ci sono due modi di rappresentare i permessi. Tra questi, la rappresentazione simbolica è probabilmente la più facile da capire e ricordare. Utilizza i simboli lettera descritti in precedenza. È possibile definire i permessi per ogni categoria di utenti (u/g/o), impostandoli in modo esplicito (con = ), aggiungendone (+) o sottraendone (-). Così la formula u=rwx,g+rw,o-r conferisce al proprietario i permessi di lettura, scrittura ed esecuzione, aggiunge i permessi di lettura e scrittura per il gruppo proprietario, e rimuove i diritti di lettura per altri utenti. I permessi non alterati con le aggiunte o sottrazioni fatte da tale comando non vengono modificati. La lettera a, per «all» (tutti), copre tutte le tre categorie di utenti, così che a=rx garantisce a tutte e tre le categorie gli stessi diritti (lettura ed esecuzione, ma non scrittura).

La rappresentazione numerica (ottale) associa ogni permesso ad un valore: 4 per la lettura, 2 per la scrittura e 1 per l'esecuzione. Ogni combinazione di permessi viene associata con la somma delle cifre. I valori vengono quindi assegnati alle diverse categorie di utenti mettendoli in fila nell'ordine consueto (proprietario, gruppo, altri).

For instance, the chmod 754 file command will set the following rights: read, write and execute for the owner (since 7 = 4 + 2 + 1); read and execute for the group (since 5 = 4 + 1); read-only for others. The 0 (zero) means no rights; thus chmod 600 file allows for read/write rights for the owner, and no rights for anyone else. The most frequent right combinations are 755 for executable files and directories, and 644 for data files.

Per rappresentare i permessi speciali, è possibile anteporre una quarta cifra a questo numero in base allo stesso principio, in cui il bit setuid, il bit setgid e lo sticky bit sono rispettivamente 4, 2 e 1. chmod 4754 assocerà il bit setuid con i permessi descritti in precedenza.

Si noti che l'uso della notazione ottale consente solo di impostare tutti i permessi in una sola volta su un file, non è possibile utilizzarla per aggiungere semplicemente un nuovo permesso, come l'accesso in lettura per il gruppo proprietario, in quanto è necessario tener conto dei diritti esistenti e calcolare il nuovo valore numerico corrispondente.

SUGGERIMENTO Operazioni ricorsive

A volte è necessario cambiare i permessi per un intero albero di file. Tutti i comandi sopra descritti hanno l'opzione -R per operare ricorsivamente in sotto-directory.

The distinction between directories and files sometimes causes problems with recursive operations. That is why the “X” letter has been introduced in the symbolic representation of rights. It also represents the right to execute, but it applies differently to directories and files.

For directories it adds executable permissions to the chosen user(s). For files, it adds the executable bit only if at least one of the users (owner, group, or others) already has executable permissions. Let's demonstrate it, because this bit can be confusing:

$ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rw-r--r-- 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod o+x test.txt
  $ ls test.txt
  -rw-r--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt
  $ chmod u+X test.txt
  $ ls test.txt
  -rwxr--r-x 1 daniel daniel 0 18. Nov 01:07 test.txt

The example shows a typical file with its default permissions: its owner can read and write it, the owner's group and all other users can read it. The next operation (u+X) won't add executable permissions for the owner of the file, because permissions to execute have not been assigned. The operation has no effect on the file. Next we assign execute rights for "other" users and repeat the operation. This time it is successful, because at least one user group already had executable permissions.

It is a misconception that this bit will only affect directories. If files and directories have mixed permissions, it is often a good idea to use the find command to locate the targets you want to operate on.

APPROFONDIMENTIumask

When an application creates a file, it assigns indicative permissions, knowing that the system automatically removes certain rights, given by the command umask. Enter umask in a shell; you will see a mask such as 0022. This is simply an octal representation of the rights to be systematically removed. In this case, the write right for the group and other users: With the above umask value, the default for directories 777 becomes 755 and the default permissions for files 666 become 644.

The system's default value is handled by pam_umask(8) and /etc/login.defs.

If you give it a new octal value, the umask command modifies the mask. Used in a shell initialization file (for example, ~/.bashrc or ~/.profile), it will effectively change the default mask for your work sessions.

9.3.2. ACLs - Access Control Lists

Many filesystems, e.g. Btrfs, Ext3, Ext4, JFS, XFS, etc., support the use of Access Control Lists (ACLs). These extend the basic features of file ownership and permission, described in the previous section, and allow for a more fine-grained control of each (file) object. For example: A user wants to share a file with another user and that user should only be able to read the file, but not write or change it.

For some of the filesystems, the usage of ACLs is enabled by default (e.g. Btrfs, Ext3, Ext4). For other filesystems or older systems it must be enabled using the acl mount option - either in the mount command directly or in /etc/fstab. In the same way the usage of ACLs can be disabled by using the noacl mount option. For Ext* filesystems one can also use the tune2fs -o [no]acl /dev/device command to enable/disable the usage of ACLs by default. The default values for each filesystem can usually be found in their homonym manual pages in section 5 (filesystem(5)) or in mount(8).

After enabling ACLs, permissions can be set using the setfacl(1) command, while getfacl(1) allows one to retrieve the ACLs for a given object or path. These commands are part of the acl package. With setfacl one can also configure newly created files or directories to inherit permissions from the parent directory. It is important to note that ACLs are processed in their order and that an earlier entry that fits the situation has precedence over later entries.

If a file has ACLs set, the output of the ls -l command will show a plus-sign after the traditional permissions. When using ACLs, the chmod command behaves slightly different, and umask might be ignored. The extensive documentation, e.g. acl(5) contains more information.