symlink - Gestion des liens symboliques
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.
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.
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.
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.
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 :
- •
- Les liens symboliques fournis en argument des appels
système sous forme de noms de fichiers.
- •
- Les liens symboliques indiqués comme arguments de la
ligne de commande pour les utilitaires qui ne parcourent pas
l'arborescence des fichiers.
- •
- 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).
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.
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).
If it is explicitly intended that the command operate on the symbolic link
instead of following the symbolic link—for example, it is desired that
chown slink change the ownership of the file that
slink is,
whether it is a symbolic link or not—then the
-h option should
be used. In the above example,
chown root slink would change the
ownership of the file referred to by
slink, while
chown -h
root slink would change the ownership of
slink itself.
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).
- •
- The ls(1) command is also an exception to this rule.
For compatibility with historic systems (when ls(1) is not doing a
tree walk—that is, -R option is not specified), the
ls(1) command follows symbolic links named as arguments if the
-H or -L option is specified, or if the -F,
-d, or -l options are not specified. (The ls(1)
command is the only command where the -H and -L options
affect its behavior even though it is not doing a walk of a file
tree.)
- •
- 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.
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 un peu
différemment. Si une option -F, -d ou -l
n’est pas précisée, 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.
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)
La traduction française de cette page de manuel a été
créée par Christophe Blaess
<
https://www.blaess.fr/christophe/>, Stéphan Rafin
<
[email protected]>, Thierry Vignaud
<
[email protected]>, François Micaux, Alain Portal
<
[email protected]>, Jean-Philippe Guérard
<
[email protected]>, Jean-Luc Coulon (f5ibh)
<
[email protected]>, Julien Cristau
<
[email protected]>, Thomas Huriaux <
[email protected]>,
Nicolas François <
[email protected]>, Florentin
Duneau <
[email protected]>, Simon Paillard
<
[email protected]>, Denis Barbier
<
[email protected]>, David Prévot <
[email protected]>,
Frédéric Hantrais <
[email protected]> et Jean-Paul
Guillonneau <
[email protected]>
Cette traduction est une documentation libre ; veuillez vous reporter
à la
GNU
General Public License version 3 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 à
[email protected]