web-dev-qa-db-fra.com

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

Disons que vous avez cette structure:

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

file3 est un lien vers un autre file3 ailleurs sur le système.

Maintenant, supposons que je chmod 777 le répertoire et tous les contenus qu’il contient. Est-ce que mon file3 dans /tmp reçoit ces autorisations? En outre, supposons que nous ayons la même situation mais inversée.

/tmp/file3 -> /directory/file3

Si j'applique les autorisations sur le fichier lié, comment cela affecte-t-il le lien?

linuxunixpermissionsfile-permissionssymbolic-link
87
n0pe

Cela dépend de la façon dont vous appelez chmod et de 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; l'appel système chmod ne peut pas modifier leurs autorisations. Ce n'est pas un problème puisque les permissions des liens symboliques ne sont jamais utilisées. Toutefois, pour chaque lien symbolique répertorié sur la ligne de commande, chmod modifie les autorisations du fichier pointé. En revanche, chmod ignore les liens symboliques rencontrés lors de parcours récursifs de répertoires.

Toutefois, sur un Mac, chmod peut être utilisé pour modifier les autorisations d'un lien symbolique à l'aide d'options telles que (à partir de man chmod):

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

À titre d'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 les autorisations de manière récursive, la cible du lien ne sera pas affectée, mais si vous modifiez chmod 777 directory/*, ce sera le cas.

Si vous modifiez directement les autorisations sur la cible du lien, ces autorisations seront conservées (étant donné que les pages de manuel et baraboom say, 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
87
peth

les réponses de baraboom et de peth sont toutes deux correctes: les bits d'autorisation sur les liens symboliques eux-mêmes ne sont pas pertinents (sauf sur macOS; voir ci-dessous), et le changement d'autorisation sur un lien symbolique - à l'aide de l'outil de ligne de commande chmod ou de l'appel système chmod() - va simplement agissez comme si cela avait été effectué 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 de 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, à l'exception de la valeur des bits de mode de fichier renvoyés dans le champ st_mode du stat la structure n'est pas spécifiée.

Ici, "non spécifié" laisse une marge d'interprétation pour chaque implémentation. Détails:

  • Sous Linux (testé avec ext4fs), stat() renvoie st_mode=0777, quelle que soit la nature de l'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 dispose de sa propre autorisation: la commande chmod -h mentionnée ci-dessus peut modifier cette autorisation de lien (qui utilise en interne un appel système non POSIX lchown() pour y parvenir), et l'appel système stat() 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'autre part, macOS casse légèrement POSIX. Bien qu'un lien symbolique puisse être suivi quelle que soit son autorisation de lecture, readlink() échoue avec EACCES (autorisation refusée) si l'utilisateur ne dispose pas de 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 la partie -> target est manquante dans la sortie de la deuxième commande ls -l et que cat symlink a tout de même réussi et a imprimé le contenu du fichier target 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, si elle est définie, entraîne des autorisations de lecture/exécution de liens symboliques pour contrôler readlink() et traverser les liens.

5
astralblue