117 votes

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 quelque part ailleurs sur le système.

Maintenant, disons que je chmod 777 le répertoire et tout le contenu qu'il contient. Est-ce que mon file3 en /tmp recevoir ces permissions ? Par ailleurs, disons que nous avons la même situation mais inversée.

/tmp/file3 -> /directory/file3

Si j'applique les permissions sur le fichier vers lequel le lien est établi, comment cela affecte-t-il le lien ?

114voto

peth Points 9170

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

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

chmod ne modifie jamais les permissions des liens symboliques ; l'option chmod l'appel système ne peut pas modifier leurs permissions. 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 le 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, changer le mode du lien lui-même plutôt que du fichier vers lequel le lien pointe.

Pour les besoins de l'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 changer récursivement les permissions, la cible du lien ne sera pas affectée, mais si vous faites chmod 777 directory/* il le fera.

Si vous modifiez les permissions sur la cible du lien directement, ces permissions seront reportées (puisque comme les pages de manuel et les pages d'accueil, les permissions sont modifiées). baraboom les autorisations de liens ne sont pas utilisées pour quoi que ce soit).


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

12voto

astralblue Points 121

Les réponses de Baraboom et de Peth sont toutes deux correctes : Les bits de permission sur les liens symboliques eux-mêmes ne sont pas pertinents (sauf sur macOS ; voir ci-dessous), et la modification de la permission sur un lien symbolique - par la commande chmod ou par l'outil de ligne de commande chmod() se comportera simplement comme s'il était effectué contre la cible du lien symbolique.

Je cite 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 la norme 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ée dans la fonction st_mode du champ de la stat est non spécifié.

Ici, "non spécifié" laisse une marge d'interprétation pour chaque mise en œuvre. Spécifique :

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

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

D'autre part, macOS enfreint légèrement POSIX. Bien qu'un lien symbolique puisse être suivi indépendamment de sa permission de lecture, readlink() échoue avec EACCES (Permission refusée) si l'utilisateur n'a pas le droit 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 est manquante dans la sortie du deuxième ls -l et que cat symlink a quand même réussi et a imprimé le contenu du target même si l'utilisateur n'avait pas le droit de lire sur le fichier symlink .)

NetBSD offre apparemment une option de montage spéciale nommée symperm qui, si elle est définie, fait en sorte que les autorisations de lecture/exécution du lien symbolique contrôlent readlink() et le franchissement de liens.

-2voto

AVA Points 113
  1. déposer le fichier de liaison (après s'être assuré qu'il n'est utilisé par aucun processus)
  2. définir umask de manière à ce que les permissions de fichiers 777-umask=requises
  3. créer à nouveau le fichier de liaison

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X