Come si applicano le autorizzazioni per i file ai collegamenti simbolici?

Diciamo che hai questa struttura:

+ directory
-- file1
-- file2
-- file3 -> /tmp/file3

file3è un collegamento a un'altra file3parte del sistema.

Ora diciamo che ho chmod 777la directory e tutti i contenuti al suo interno. Il mio file3in /tmpriceve tali autorizzazioni? Inoltre, supponiamo di avere la stessa situazione ma al contrario.

/tmp/file3 -> /directory/file3

Se applico i permessi sul file a cui sono collegato, come influisce sul collegamento?

Dipende da come chiami chmode dalla piattaforma su cui stai girando.

Ad esempio, su un sistema Linux, man chmoddice questo:

chmod non modifica mai le autorizzazioni dei collegamenti simbolici; la chmod chiamata di sistema non può cambiare le loro autorizzazioni. Questo non è un problema poiché le autorizzazioni dei collegamenti simbolici non vengono mai utilizzate. Tuttavia, per ciascun collegamento simbolico elencato nella riga di comando, chmodmodifica le autorizzazioni del file puntato. Al contrario, chmodignora i collegamenti simbolici rilevati durante gli attraversamenti ricorsivi delle directory.

Tuttavia, su un Mac, chmod può essere utilizzato per modificare le autorizzazioni di un collegamento simbolico utilizzando opzioni come questa (da man chmod):

-h Se il file è un collegamento simbolico, modificare la modalità del collegamento stesso anziché il file a cui punta il collegamento.

Per esempio, supponiamo che tu sia su una macchina Linux per il resto di questa risposta.

Se nel primo caso si esegue chmod -R 777 directoryper modificare in modo ricorsivo le autorizzazioni, la destinazione del collegamento non sarà interessata, ma in tal caso chmod 777 directory/*lo sarà.

Se si modificano direttamente le autorizzazioni sulla destinazione del collegamento, tali autorizzazioni verranno applicate (poiché, come dicono la pagina man e il baraboom , le autorizzazioni del collegamento effettive non vengono utilizzate per nulla).

Registro di prova per illustrazione:

$ mkdir dir && touch dir/file{1,2} /tmp/file3 && ln -s {/tmp,dir}/file3
$ ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file1
-rw-r--r-- 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod -R 777 dir && ls -l dir/* /tmp/file3
-rw-r--r-- 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file1
-rwxrwxrwx 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

$ chmod 700 dir/* && ls -l dir/* /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 /tmp/file3
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file1
-rwx------ 1 user group  0 2011-06-27 22:02 dir/file2
lrwxrwxrwx 1 user group 10 2011-06-27 22:02 dir/file3 -> /tmp/file3

Le risposte di baraboom e peth sono entrambe corrette: i bit di autorizzazione sui collegamenti simbolici stessi sono irrilevanti (eccetto su macOS; vedi sotto) e la modifica dei permessi su un collegamento simbolico - tramite lo chmodstrumento da riga di comando o dalla chmod()chiamata di sistema - agirà semplicemente come se è stato eseguito contro l'obiettivo del collegamento simbolico.

Per citare la descrizione SUSv4 / POSIX.1-2008 della chiamata di sistema symlink () :

I valori dei bit della modalità file per il collegamento simbolico creato non sono specificati. Tutte le interfacce specificate da POSIX.1-2008 devono comportarsi come se i contenuti dei collegamenti simbolici possano sempre essere letti, tranne per il fatto che il valore dei bit della modalità file restituiti nel campo st_mode della struttura stat non è specificato.

Qui, "non specificato" lascia spazio all'interpretazione per ogni implementazione. specifiche:

• Su Linux (testato usando ext4fs), stat()ritorna st_mode=0777, non importa quale fosse l'umask quando è stato creato il collegamento simbolico; ls -lpertanto viene sempre visualizzato lrwxrwxrwxper i collegamenti simbolici.
• Su macOS (HFS) e FreeBSD (sia UFS che ZFS), un collegamento simbolico ha una propria autorizzazione: il chmod -hcomando indicato sopra può modificare questa autorizzazione di collegamento (che utilizza internamente una lchown()chiamata di sistema non POSIX per raggiungere questo obiettivo), e il stat()sistema call restituisce questo valore per st_mode.

I collegamenti simbolici su Linux e FreeBSD possono sempre essere seguiti, come specificato da POSIX. In particolare, su FreeBSD, ciò significa che la modalità file di un collegamento simbolico non ha alcun effetto sul controllo degli accessi.

D'altra parte, macOS rompe leggermente POSIX. Sebbene sia possibile seguire un collegamento simbolico indipendentemente dall'autorizzazione di lettura, readlink()non riesce con EACCES(Autorizzazione negata) se l'utente non dispone dell'autorizzazione di lettura:

$ sudo ln -shf target symlink
$ sudo chmod -h 444 symlink
$ ls -l symlink
lr--r--r--  1 root  staff  1 Mar 14 13:05 symlink -> target
$ sudo chmod -h 000 symlink
$ ls -l symlink

ls: symlink: Permission denied
l---------  1 root  staff  1 Mar 14 13:05 symlink
$ echo kthxbye > target
$ cat symlink
kthxbye

(Si noti che la -> targetparte non è presente nell'output del secondo ls -lcomando e che è cat symlinkcomunque riuscita e stampato il contenuto del targetfile anche se l'utente non aveva l'autorizzazione di lettura symlink.)

Apparentemente NetBSD offre un'opzione di montaggio speciale denominata sympermche, se impostata, causa autorizzazioni di lettura / esecuzione del collegamento simbolico per controllare readlink()e attraversare il collegamento.

1. rilasciare il file di collegamento (dopo aver verificato che non sia utilizzato da alcun processo)
2. impostare umask in modo tale che il 777-umask = permessi sui file richiesti
3. creare nuovamente il file di collegamento