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

Disons que vous avez cette structure:

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

file3est un lien vers un autre file3endroit du système.

Maintenant, disons que je chmod 777le répertoire et tous les contenus qu'il contient. Est-ce que mon file3en /tmpreç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?

Cela dépend de la façon dont vous appelez chmodet de la plate-forme sur laquelle vous vous trouvez.

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

chmod ne change jamais les permissions des liens symboliques; l' chmod 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. Toutefois, pour chaque lien symbolique répertorié sur la ligne de commande, chmodmodifie les autorisations du fichier pointé. En revanche, chmodignore les liens symboliques rencontrés lors de parcours récursifs de répertoires.

Cependant, 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 directoryune modification récursive des autorisations, la cible du lien ne sera pas affectée mais, dans le cas contraire chmod 777 directory/*, elle le sera.

Si vous modifiez directement les autorisations sur la cible du lien, ces autorisations seront conservées (puisque, comme l' indiquent les pages de manuel et baraboom , les autorisations de lien réelles ne sont utilisées à aucune fin).

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 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 - par l' chmodoutil de ligne de commande ou par l' chmod()appel système - agira simplement comme si elle a été effectuée 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, sauf que la valeur des bits de mode de fichier retournés dans le champ st_mode de la structure stat 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), les stat()retours st_mode=0777, quel que soit le umask utilisé lors de la création du lien symbolique; ls -laffiche donc toujours lrwxrwxrwxpour les liens symboliques.
• Sur macOS (HFS) et FreeBSD (UFS et ZFS), un lien symbolique dispose de sa propre autorisation: la chmod -hcommande décrite ci-dessus peut modifier cette autorisation (qui utilise en interne un lchown()appel système non POSIX pour y parvenir), et le stat()système call 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 -> targetpartie est manquante dans la sortie de la deuxième ls -lcommande et qu'elle a quand même cat symlinkréussi et imprimé le contenu du targetfichier même si l'utilisateur n'avait pas l'autorisation de lecture symlink.)

NetBSD propose apparemment une option de montage spéciale nommée sympermqui, si définie, entraîne des autorisations de lecture / exécution de lien symbolique pour contrôler readlink()et traverser les liens.

1. déposer le fichier de lien (après s'être assuré qu'il n'est utilisé par aucun processus)
2. définissez umask de telle sorte que 777-umask = autorisations de fichier requises
3. créer à nouveau le fichier de lien