Provided by: manpages-fr_4.13-4_all 
NOM
symlink – Gestion des liens symboliques
DESCRIPTION
Les liens symboliques sont des fichiers qui agissent comme des pointeurs vers d'autres
fichiers. Pour comprendre leur fonctionnement, vous devez d'abord comprendre comment
fonctionnent les liens physiques.
Un lien physique (hard link) vers un fichier est indistinguable du fichier d'origine, car
c'est une référence directe vers l'objet sous-jacent pointé par le nom originel. (Pour
être précis, chaque lien physique sur un fichier fait référence au même numéro d'inœud, ce
numéro étant un indice dans une table d'inœuds qui contient des métadonnées sur tout le
contenu du système de fichiers. Consultez stat(2)). Les changements dans un fichier sont
indépendants du nom utilisé pour faire référence au fichier. Les liens physiques ne
peuvent pas faire référence aux répertoires (pour éviter le risque de boucles dans
l’arborescence du système de fichiers, ce qui planterait de nombreux programmes) et ne
peuvent pas référencer des fichiers sur un autre système de fichiers (car les numéros
d'inœud ne sont uniques que sur un même système de fichiers).
Un lien symbolique est un fichier d'un type spécial, dont le contenu est une chaîne
représentant le chemin d'accès vers un autre fichier, celui vers lequel le lien pointe.
(Le contenu d'un lien symbolique peut être lu en utilisant readlink(2).) En d'autres
termes, un lien symbolique est un pointeur vers un autre nom, pas vers le contenu
sous-jacent. Pour cette raison, les liens symboliques peuvent faire référence aux
répertoires et peuvent franchir les frontières des systèmes de fichiers.
Il n'y a pas d'obligation pour que le fichier dont le nom est référencé par un lien
symbolique existe. Un lien symbolique qui fait référence à un nom de fichier inexistant
est dit dangling link (pendouillant).
Comme un lien symbolique et l'objet qu'il référence coexistent sur le système de fichiers,
une confusion peut survenir pour distinguer le lien lui-même et l'objet référencé. Sur des
systèmes historiques, les commandes et les appels système adoptaient leur propres
conventions pour le suivi des liens symboliques de manière arbitraire. Des règles pour une
approche plus uniforme, comme elles sont implémentées sur Linux et d'autres systèmes, sont
présentées ici. Il est important que les applications locales se conforment aussi à ces
règles pour que l'interface avec l'utilisateur soit la plus cohérente possible.
Liens magiques
Il existe une classe spéciale d’objets ressemblant aux liens symboliques connus comme
« liens magiques » qui peuvent être trouvés dans certains pseudo-systèmes de fichiers tels
que proc(5) (par exemple, /proc/[pid]/exe et /proc/[pid]/fd/*). Au contraire des liens
symboliques, les liens magiques ne sont pas résolus au travers d’une expansion de noms de
chemin, mais agissent plutôt comme des références directes vers la propre représentation
du noyau de la gestion de fichier. Comme tels, ces liens magiques permettent aux
utilisateurs d’accéder à des fichiers qui ne peuvent être référencés par des chemins
normaux (tels que des fichiers déliés encore référencés par un programme en cours
d’exécution).
Parce qu’ils peuvent contourner les restrictions ordinaires basées sur
mount_namespaces(7), les liens magiques ont été utilisés comme vecteur d’attaque dans
divers exploits.
Propriétés, permissions et horodatage des liens symboliques
Le propriétaire et le groupe d'un lien symbolique existant peuvent être modifiés en
utilisant lchown(2). Le seul moment où l'appartenance d'un lien symbolique est importante
est lors de sa suppression ou de son renommage dans un répertoire dont le bit « Sticky »
est positionné (consultez stat(2)).
Les horodatages du dernier accès et de la dernière modification d'un lien symbolique
peuvent être modifiés en utilisant utimensat(2) ou lutimes(3).
Sur Linux, les permissions associées à un lien symbolique ordinaire ne sont utilisées dans
aucune opération. Ces permissions sont toujours 0777 (lecture, écriture et exécution pour
toutes les catégories d'utilisateurs) et ne peuvent pas être modifiées.
Cependant, les liens magiques ne suivent pas cette règle. Ils peuvent avoir un mode
différent de 0777, bien que ce mode ne soit pas actuellement utilisé pour la vérification
des permissions.
Obtention d’un descripteur de fichier faisant référence à un lien symbolique.
L'utilisation des indicateurs O_PATH et O_NOFOLLOW en association pour un appel open(2)
délivre un descripteur de fichier qui peut être transmis comme l'argument dirfd à des
appels système tels que fstatat(2), fchownat(2), fchmodat(2), linkat(2) et readlinkat(2),
afin d'agir sur des liens symboliques eux-mêmes (et non sur les fichiers vers lesquels ils
pointent).
Par défaut (c'est-à-dire si l'indicateur AT_SYMLINK_FOLLOW n'est pas précisé), lorsque
name_to_handle_at(2) est utilisée sur un lien symbolique, il délivre un gestionnaire pour
le lien symbolique (et non pour le fichier vers lequel il pointe). On peut alors obtenir
un descripteur de fichier du lien symbolique (et non du fichier vers lequel il pointe) en
précisant l'indicateur O_PATH lors d'un appel ultérieur à open_by_handle_at(2). De
nouveau, ce descripteur de fichier peut être utilisé dans des appels système cités
précédemment pour agir sur le lien symbolique lui-même.
Traitement des liens symboliques par les appels système et les commandes
Les liens symboliques sont traités en agissant soit sur le lien lui-même, soit sur l'objet
pointé par le lien. Dans ce dernier cas, on dit que l'application ou l'appel système suit
le lien. Les liens symboliques peuvent faire référence à d'autres liens symboliques,
auquel cas les liens sont suivis jusqu'à ce qu'un objet qui n'est pas un lien symbolique
soit rencontré, qu'un lien symbolique pointant sur un fichier inexistant soit trouvé, ou
qu'une boucle soit détectée (la détection des boucles est faite en définissant une limite
maximale sur le nombre de liens qui peuvent être suivis, et une erreur se produit si cette
limite est atteinte).
Il faut considérer trois domaines d'utilisation différents des liens symboliques. Ce
sont :
1. Les liens symboliques fournis en argument des appels système sous forme de noms de
fichiers.
2. Les liens symboliques indiqués comme arguments de la ligne de commande pour les
utilitaires qui ne parcourent pas l'arborescence des fichiers.
3. Les liens symboliques rencontrés par les utilitaires qui traversent l'arborescence
(soit indiqués sur la ligne de commande, soit rencontrés comme partie de la hiérarchie
des fichiers).
Avant de décrire le traitement des liens symboliques par les appels système et les
commandes, quelques explications technologiques sont nécessaires. Étant donné un nom de
chemin de la forme a/b/c, la partie précédant la barre oblique finale (c’est-à-dire a/b)
est appelée la composante dirname (nom de répertoire) et la partie suivant la barre
oblique finale (c’est-à-dire c) est appelée la composante basename (nom de base).
Traitement des liens symboliques par les appels système
Le premier domaine est celui des liens symboliques utilisés en noms de fichiers comme
argument pour les appels système.
Le traitement des liens symboliques dans un nom de chemin passé à un appel système est le
suivant :
1. Dans la composante du nom de répertoire d’un chemin, les liens symboliques sont
toujours suivis dans presque tous les appels système (cela est aussi vrai pour les
commandes). La seule exception est openat2(2) qui fournit des indicateurs pouvant être
utilisés pour empêcher explicitement le suivi de liens symboliques dans la composante
du nom de répertoire.
2. Sauf exceptions mentionnées ci-dessous, tous les appels système suivent les liens
symboliques dans la composante du nom de base d’un chemin. Par exemple, s'il existe un
lien symbolique slink qui pointe vers un fichier appelé un_fichier, l'appel système
open("slink" ...) renverra un descripteur de fichier faisant référence à un_fichier.
Certains appels système ne suivent pas les liens symboliques dans la composante du nom de
base d’un chemin et agissent sur le lien symbolique lui-même. Ce sont : lchown(2),
lgetxattr(2), llistxattr(2), lremovexattr(2), lsetxattr(2), lstat(2), readlink(2),
rename(2), rmdir(2) et unlink(2).
Certains autres appels système suivent éventuellement les liens symboliques dans la
composante du nom de base d’un chemin. Il s'agit de : faccessat(2), fchownat(2),
fstatat(2), linkat(2), name_to_handle_at(2), open(2), openat(2), open_by_handle_at(2) et
utimensat(2). Reportez-vous à leur pages de manuel pour plus de détails. Comme remove(3)
est un alias pour unlink(2), cette fonction de bibliothèque ne suit pas non plus les liens
symboliques. Quand rmdir(2) est utilisée sur un lien symbolique, elle échoue avec l'erreur
ENOTDIR.
L'appel link(2) réclame une discussion particulière. POSIX.1-2001 précise que link(2) doit
déréférencer ancien_chemin si c'est un lien symbolique. Néanmoins, Linux ne le fait pas.
(Par défaut, Solaris non plus, mais des options de compilation permettent d'obtenir le
comportement POSIX.1-2001). POSIX.1-2008 a modifié la spécification pour permettre les
deux comportements dans une implémentation.
Commandes ne parcourant pas les arborescences de fichiers
Le second domaine est celui des liens symboliques, indiqués en tant que noms de fichiers,
comme argument pour des commandes ne traversant pas les arborescences.
Sauf exception mentionnée ci-dessous, les commandes suivent les liens symboliques fournis
en argument de ligne de commande. Par exemple, si un lien symbolique slink pointe vers un
fichier nommé un_fichier, la commande cat slink affichera le contenu du fichier
un_fichier.
Notez bien que cette règle s'applique à des commandes qui peuvent dans d'autres situations
parcourir l'arborescence, par exemple la commande chown fichier suit cette règle, alors
que chown -R fichier, qui descend l'arborescence, ne la suit pas. (Cette dernière est
traitée dans la troisième partie ci-dessous).
Si on désire qu'une commande agisse sur le lien symbolique lui-même plutôt qu'en le
suivant — par exemple si on veut que chown slink change le propriétaire du fichier slink,
que ce soit un lien symbolique ou non — l'option -h doit être utilisée. Dans cet exemple,
la commande chown root slink modifierait le propriétaire du fichier référencé par slink,
tandis que chown -h root slink modifierait le propriétaire de slink lui-même.
Il y a quelques exceptions à cette règle :
– Les commandes mv(1) et rm(1) ne suivent pas les liens symboliques fournis en argument,
mais essayent respectivement de les renommer ou de les détruire. (Notez que lorsqu'un
lien symbolique fait référence à un fichier par un chemin relatif, il peut cesser de
fonctionner si on le déplace dans un autre répertoire puisque le chemin relatif ne
serait plus correct).
– La commande ls(1) est aussi une exception à cette règle. Pour assurer la compatibilité
avec des systèmes historiques (quand ls(1) ne descend pas une arborescence
— c'est-à-dire si l'option -R n'est pas présente), la commande ls(1) suit les liens
symboliques fournis en argument si les options -H ou -L sont indiquées ou si les options
-F, -d et -l ne sont pas présentes (la commande ls(1) est la seule dont les options -H
et -L modifient le comportement même lorsqu'elle ne fait pas un parcours
d'arborescence).
– La commande file(1) est aussi une exception à cette règle. Par défaut, la commande
file(1) ne suit pas les liens symboliques fournis en argument. La commande file(1) ne
les suit que si l'option -L est mentionnée.
Commandes parcourant une arborescence
Les commandes suivantes parcourent, toujours ou sur option, l'arborescence des fichiers :
chgrp(1), chmod(1), chown(1), cp(1), du(1), find(1), ls(1), pax(1), rm(1) et tar(1).
Il est important de remarquer que les règles ci-dessous s'appliquent tant aux liens
symboliques rencontrés durant un parcours d'arborescence qu'aux liens fournis en argument
de ligne de commande.
La première règle s'applique aux liens qui référencent des fichiers autres que des
répertoires. Les opérations entreprises sur ces liens sont appliquées sur les liens
eux-mêmes, ou alors les liens sont ignorés.
La commande rm -r slink répertoire effacera slink, ainsi que tout lien symbolique
rencontré durant le parcours dans le répertoire, car les liens symboliques peuvent être
effacés. En aucun cas rm(1) ne touchera au fichier référencé par slink.
La seconde règle s'applique aux liens symboliques qui pointent vers des répertoires. Par
défaut, ces liens ne sont jamais suivis. Cela est souvent appelé un parcours « physique »
par opposition à un parcours « logique » (où les liens symboliques vers des répertoires
seraient suivis).
Certaines conventions sont (ou devraient être) respectées autant que possible par les
commandes parcourant des arborescences de fichiers :
– Une commande peut être forcée à suivre n'importe quel lien symbolique indiqué sur la
ligne de commande, quel que soit le type de fichier vers lequel il pointe, en utilisant
l'option -H (pour « half-logical »). Cette option permet d'avoir un espace de noms de la
ligne de commande conforme à l'espace de noms logique. (Notez que pour les commandes qui
ne parcourent pas toujours l'arborescence, l'option -H sera ignorée si l'option -R n'est
pas également présente.)
Par exemple, la commande chown -HR utilisateur slink parcourra la hiérarchie de fichiers
débutant par le fichier pointé par slink. Remarquez que l'option -H n'est pas la même
que l'option -h traitée précédemment. L'option -H permet de suivre les liens symboliques
indiqués sur la ligne de commande aussi bien pour l'action à exécuter que pour le
parcours de l'arborescence ; tout se passe comme si l'utilisateur avait fourni le nom du
fichier référencé par le lien symbolique.
– Une commande peut être forcée à suivre les liens symboliques nommés sur sa ligne de
commande, ainsi que tous les liens rencontrés durant le parcours, quel que soit le type
des fichiers qu'ils référencent, en utilisant l'option -L (pour « logical »). Cette
option permet de rendre l'espace de noms en entier semblable à l'espace de noms logique.
Notez que les commandes qui ne font pas systématiquement de parcours d'arborescence
ignoreront l'option -L si l'option -R n'est pas présente.
Par exemple, la commande chown -LR utilisateur slink modifiera le propriétaire du
fichier référencé par slink. Si slink pointe vers un répertoire, chown(1) descendra
l'arborescence à partir de ce répertoire. En outre, si des liens symboliques sont
rencontrés pendant le parcours de chown(1), ils seront traités de la même façon que
slink.
– Une commande peut être forcée à employer le comportement par défaut en utilisant
l'option -P (pour « physique »). Cet attribut permet de rendre l'espace de noms
semblable à l'espace de noms physique.
Pour les commandes qui ne parcourent pas d'arborescence par défaut, les options -H, -L et
-P sont ignorées si l'option -R n'est pas présente. De plus, vous pouvez indiquer -H, -L
et -P plusieurs fois ; c'est la dernière option qui déterminera le comportement de la
commande. Cela permet de créer des alias de commandes afin d'avoir un comportement choisi
et de surcharger ce comportement en ligne de commande.
Les commandes ls(1) et rm(1) présentent des exceptions pour ces règles :
– La commande rm(1) agit toujours sur le lien symbolique et jamais sur le fichier qu'il
référence. Ainsi le lien n'est jamais suivi. La commande rm(1) ne prend pas en charge
les options -H, -L ou -P.
– Afin d'assurer une compatibilité avec les systèmes historiques, la commande ls(1) agit
quelque peu différemment. Si on ne précise pas d'option -F, -d ou -l, alors ls(1) suivra
les liens indiqués sur la ligne de commande. Si l'option -L est mentionnée, ls(1) suivra
tous les liens symboliques, quels que soient leurs types, qu'ils soient fournis sur la
ligne de commande ou rencontrés en parcourant l'arborescence.
VOIR AUSSI
chgrp(1), chmod(1), find(1), ln(1), ls(1), mv(1), namei(1), rm(1), lchown(2), link(2),
lstat(2), readlink(2), rename(2), symlink(2), unlink(2), utimensat(2), lutimes(3),
path_resolution(7)
COLOPHON
Cette page fait partie de la publication 5.10 du projet man-pages Linux. Une description
du projet et des instructions pour signaler des anomalies et la dernière version de cette
page peuvent être trouvées à l'adresse https://www.kernel.org/doc/man-pages/.
TRADUCTION
La traduction française de cette page de manuel a été créée par Christophe Blaess
<https://www.blaess.fr/christophe/>, Stéphan Rafin <stephan.rafin@laposte.net>, Thierry
Vignaud <tvignaud@mandriva.com>, François Micaux, Alain Portal <aportal@univ-montp2.fr>,
Jean-Philippe Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas Huriaux
<thomas.huriaux@gmail.com>, Nicolas François <nicolas.francois@centraliens.net>, Florentin
Duneau <fduneau@gmail.com>, Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis
Barbier <barbier@debian.org>, David Prévot <david@tilapin.org>, Frédéric Hantrais
<fhantrais@gmail.com> et Jean-Paul Guillonneau <guillonneau.jeanpaul@free.fr>
Cette traduction est une documentation libre ; veuillez vous reporter à la GNU General
Public License version 3 ⟨https://www.gnu.org/licenses/gpl-3.0.html⟩ concernant les
conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un
message à debian-l10n-french@lists.debian.org ⟨⟩.