Come si applicano i permessi dei file ai collegamenti simbolici?

Dipende da come chiami chmod e la piattaforma su cui stai girando.

Ad esempio, su un sistema Linux, man chmod dice questo:

chmod non cambia mai i permessi dei collegamenti simbolici; il chmod la chiamata di sistema non può modificare i propri permessi. Questo non è un problema poiché i permessi dei collegamenti simbolici non vengono mai utilizzati. Tuttavia, per ogni collegamento simbolico elencato nella riga di comando, chmod cambia i permessi del file puntato. Al contrario, chmod ignora i collegamenti simbolici incontrati durante gli attraversamenti ricorsivi delle directory.

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

-h Se il file è un collegamento simbolico, cambia 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 esegui chmod -R 777 directory per modificare in modo ricorsivo le autorizzazioni, la destinazione del collegamento non sarà influenzata, ma se esegui chmod 777 directory/* , lo farà.

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

Registro di prova per esempio:

$ 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 (tranne che su macOS; vedi sotto) e la modifica dell'autorizzazione su un collegamento simbolico - tramite il chmod strumento da riga di comando o dal chmod() chiamata di sistema – agirà semplicemente come se fosse eseguita 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 il contenuto dei collegamenti simbolici potesse sempre essere letto, tranne per il valore dei bit della modalità file restituiti in st_mode campo della stat la struttura non è specificata.

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

• Su Linux (testato usando ext4fs), stat() restituisce st_mode=0777 , non importa quale fosse l'umask quando è stato creato il collegamento simbolico; ls -l pertanto visualizza sempre lrwxrwxrwx per collegamenti simbolici.
• Su macOS (HFS) e FreeBSD (sia UFS che ZFS), un collegamento simbolico ha il proprio permesso:chmod -h Il comando sopra indicato può modificare questo permesso di collegamento (che utilizza internamente un lchown() non POSIX chiamata di sistema per raggiungere questo obiettivo) e stat() la chiamata di sistema 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 interrompe leggermente POSIX. Sebbene un collegamento simbolico possa essere seguito indipendentemente dal suo permesso di lettura, readlink() fallisce con EACCES (Permesso negato) se l'utente non ha il permesso 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

(Notare che il -> target parte manca nell'output del secondo ls -l comando, e quel cat symlink è comunque riuscito e ha stampato il contenuto di target file anche se l'utente non aveva il permesso di lettura su symlink .)

Apparentemente NetBSD offre una speciale opzione di montaggio denominata symperm che, se impostato, provoca i permessi di lettura/esecuzione del collegamento simbolico per controllare readlink() e attraversamento dei collegamenti.