Comment les autorisations de fichiers s'appliquent-elles aux liens symboliques ?

Cela dépend de la façon dont vous appelez chmod et la plate-forme sur laquelle vous exécutez.

Par exemple, sur un système Linux, man chmod dit ceci :

chmod ne change jamais les permissions des liens symboliques ; le chmod l'appel système ne peut pas modifier leurs autorisations. Ce n'est pas un problème puisque les permissions des liens symboliques ne sont jamais utilisées. Cependant, pour chaque lien symbolique listé sur la ligne de commande, chmod modifie les permissions du fichier pointé. En revanche, chmod ignore les liens symboliques rencontrés lors des parcours récursifs de répertoires.

Cependant, sur un Mac, chmod peut être utilisé pour modifier les permissions d'un lien symbolique en utilisant des options telles que celle-ci (à partir de man chmod ):

-h Si le fichier est un lien symbolique, change le mode du lien lui-même plutôt que le fichier vers lequel pointe le lien.

Par exemple, supposons que vous êtes sur une machine Linux pour le reste de cette réponse.

Si dans le premier cas vous exécutez chmod -R 777 directory pour modifier récursivement les autorisations, la cible du lien ne sera pas affectée, mais si vous faites chmod 777 directory/* , ça va.

Si vous modifiez directement les autorisations sur la cible du lien, ces autorisations seront appliquées (puisque, comme le disent la page de manuel et baraboom, les autorisations de lien réelles ne sont utilisées pour rien).

Journal de test pour illustration :

$ 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

Les réponses de baraboom et de peth sont toutes les deux correctes :les bits d'autorisation sur les liens symboliques eux-mêmes ne sont pas pertinents (sauf sur macOS ; voir ci-dessous), et la modification de l'autorisation sur un lien symbolique - par le chmod outil en ligne de commande ou par le chmod() appel système - agira simplement comme s'il était exécuté contre la cible du lien symbolique.

Pour citer la description SUSv4/POSIX.1-2008 de l'appel système symlink() :

Les valeurs des bits de mode fichier pour le lien symbolique créé ne sont pas spécifiées. Toutes les interfaces spécifiées par POSIX.1-2008 doivent se comporter comme si le contenu des liens symboliques pouvait toujours être lu, sauf que la valeur des bits de mode fichier renvoyés dans le st_mode champ de la stat la structure n'est pas spécifiée.

Ici, "non spécifié" laisse place à l'interprétation de chaque implémentation. Spécificités :

• Sous Linux (testé avec ext4fs), stat() renvoie st_mode=0777 , quel que soit le umask lors de la création du lien symbolique ; ls -l affiche donc toujours lrwxrwxrwx pour les liens symboliques.
• Sur macOS (HFS) et FreeBSD (UFS et ZFS), un lien symbolique a sa propre permission :le chmod -h la commande indiquée ci-dessus peut modifier cette autorisation de lien (qui utilise en interne un lchown() non POSIX appel système pour y parvenir), et le stat() l'appel système renvoie cette valeur pour st_mode .

Les liens symboliques sous Linux et FreeBSD peuvent toujours être suivis, comme spécifié par POSIX. En particulier, sous FreeBSD, cela signifie que le mode fichier d'un lien symbolique n'a aucun effet sur le contrôle d'accès.

D'un autre côté, macOS casse légèrement POSIX. Bien qu'un lien symbolique puisse être suivi quelle que soit sa permission de lecture, readlink() échoue avec EACCES (Autorisation refusée) si l'utilisateur n'a pas l'autorisation de lecture :

$ 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

(Notez que le -> target partie est manquante dans la sortie du deuxième ls -l commande, et que cat symlink toujours réussi et imprimé le contenu du target fichier même si l'utilisateur n'avait pas l'autorisation de lecture sur symlink .)

NetBSD propose apparemment une option de montage spéciale nommée symperm qui, s'il est défini, provoque des autorisations de lecture/exécution de lien symbolique pour contrôler readlink() et traversée de liens.