.\" -*- coding: UTF-8 -*- .\" Copyright (c) 1992, 1993, 1994 .\" The Regents of the University of California. All rights reserved. .\" and Copyright (C) 2008, 2014 Michael Kerrisk .\" .\" SPDX-License-Identifier: BSD-3-Clause .\" .\" @(#)symlink.7 8.3 (Berkeley) 3/31/94 .\" $FreeBSD: src/bin/ln/symlink.7,v 1.30 2005/02/13 22:25:09 ru Exp $ .\" .\" 2008-06-11, mtk, Taken from FreeBSD 6.2 and heavily edited for .\" specific Linux details, improved readability, and man-pages style. .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH symlink 7 "5 février 2023" "Pages du manuel de Linux 6.03" .SH NOM symlink \- Gestion des liens symboliques .SH 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. .PP 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 \fInuméro d'inœud\fP, 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 \fBstat\fP(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). .PP 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 \fBreadlink\fP(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. .PP 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 \fIdangling link\fP (pendouillant). .PP .\" 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. .SS "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 \fBproc\fP(5) (par exemple, \fI/proc/[pid]/exe\fP et \fI/proc/[pid]/fd/*\fP). 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). .PP .\" Parce qu’ils peuvent contourner les restrictions ordinaires basées sur \fBmount_namespaces\fP(7), les liens magiques ont été utilisés comme vecteur d’attaque dans divers exploits. .SS "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 \fBlchown\fP(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 \fBstat\fP(2)). .PP Les horodatages du dernier accès et de la dernière modification d'un lien symbolique peuvent être modifiés en utilisant \fButimensat\fP(2) ou \fBlutimes\fP(3). .PP .\" Linux does not currently implement an lchmod(2). 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. .PP .\" .PP .\" The .\" 4.4BSD .\" system differs from historical .\" 4BSD .\" systems in that the system call .\" .BR chown (2) .\" has been changed to follow symbolic links. .\" The .\" .BR lchown (2) .\" system call was added later when the limitations of the new .\" .BR chown (2) .\" became apparent. 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. .SS "Obtention d’un descripteur de fichier faisant référence à un lien symbolique." L'utilisation des indicateurs \fBO_PATH\fP et \fBO_NOFOLLOW\fP en association pour un appel \fBopen\fP(2) délivre un descripteur de fichier qui peut être transmis comme l'argument \fIdirfd\fP à des appels système tels que \fBfstatat\fP(2), \fBfchownat\fP(2), \fBfchmodat\fP(2), \fBlinkat\fP(2) et \fBreadlinkat\fP(2), afin d'agir sur des liens symboliques eux\-mêmes (et non sur les fichiers vers lesquels ils pointent). .PP Par défaut (c'est\-à\-dire si l'indicateur \fBAT_SYMLINK_FOLLOW\fP n'est pas précisé), lorsque \fBname_to_handle_at\fP(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 \fBO_PATH\fP lors d'un appel ultérieur à \fBopen_by_handle_at\fP(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. .SS "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 \fIsuit\fP 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). .PP Il faut considérer trois domaines d'utilisation différents des liens symboliques. Ce sont\ : .IP \[bu] 3 Les liens symboliques fournis en argument des appels système sous forme de noms de fichiers. .IP \[bu] Les liens symboliques indiqués comme arguments de la ligne de commande pour les utilitaires qui ne parcourent pas l'arborescence des fichiers. .IP \[bu] 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). .PP .\" 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 \fIa/b/c\fP, la partie précédant la barre oblique finale (c’est\-à\-dire \fIa/b\fP) est appelée la composante \fIdirname\fP (nom de répertoire) et la partie suivant la barre oblique finale (c’est\-à\-dire \fIc\fP) est appelée la composante \fIbasename\fP (nom de base). .SS "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. .PP Le traitement des liens symboliques dans un nom de chemin passé à un appel système est le suivant\ : .IP (1) 5 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 \fBopenat2\fP(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. .IP (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 \fIslink\fP qui pointe vers un fichier appelé \fIun_fichier\fP, l'appel système \fIopen("slink" ...\&)\fP renverra un descripteur de fichier faisant référence à \fIun_fichier\fP. .PP 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\ : \fBlchown\fP(2), \fBlgetxattr\fP(2), \fBllistxattr\fP(2), \fBlremovexattr\fP(2), \fBlsetxattr\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBrmdir\fP(2) et \fBunlink\fP(2). .PP .\" Maybe one day: .BR fchownat (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\ : \fBfaccessat\fP(2), \fBfchownat\fP(2), \fBfstatat\fP(2), \fBlinkat\fP(2), \fBname_to_handle_at\fP(2), \fBopen\fP(2), \fBopenat\fP(2), \fBopen_by_handle_at\fP(2) et \fButimensat\fP(2). Reportez\-vous à leur pages de manuel pour plus de détails. Comme \fBremove\fP(3) est un alias pour \fBunlink\fP(2), cette fonction de bibliothèque ne suit pas non plus les liens symboliques. Quand \fBrmdir\fP(2) est utilisée sur un lien symbolique, elle échoue avec l'erreur \fBENOTDIR\fP. .PP L'appel \fBlink\fP(2) réclame une discussion particulière. POSIX.1\-2001 précise que \fBlink\fP(2) doit déréférencer \fIancien_chemin\fP 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. .SS "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. .PP 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 \fIslink\fP pointe vers un fichier nommé \fIun_fichier\fP, la commande \fIcat\ slink\fP affichera le contenu du fichier \fIun_fichier\fP. .PP Notez bien que cette règle s'applique à des commandes qui peuvent dans d'autres situations parcourir l'arborescence, par exemple la commande \fIchown\ fichier\fP suit cette règle, alors que \fIchown\ \-R\ fichier\fP, qui descend l'arborescence, ne la suit pas. (Cette dernière est traitée dans la troisième partie ci\-dessous). .PP If it is explicitly intended that the command operate on the symbolic link instead of following the symbolic link\[em]for example, it is desired that \fIchown slink\fP change the ownership of the file that \fIslink\fP is, whether it is a symbolic link or not\[em]then the \fI\-h\fP option should be used. In the above example, \fIchown root slink\fP would change the ownership of the file referred to by \fIslink\fP, while \fIchown\ \-h root slink\fP would change the ownership of \fIslink\fP itself. .PP Il y a quelques exceptions à cette règle\ : .IP \[bu] 3 Les commandes \fBmv\fP(1) et \fBrm\fP(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). .IP \[bu] The \fBls\fP(1) command is also an exception to this rule. For compatibility with historic systems (when \fBls\fP(1) is not doing a tree walk\[em]that is, \fI\-R\fP option is not specified), the \fBls\fP(1) command follows symbolic links named as arguments if the \fI\-H\fP or \fI\-L\fP option is specified, or if the \fI\-F\fP, \fI\-d\fP, or \fI\-l\fP options are not specified. (The \fBls\fP(1) command is the only command where the \fI\-H\fP and \fI\-L\fP options affect its behavior even though it is not doing a walk of a file tree.) .IP \[bu] .\" .\"The 4.4BSD system differs from historical 4BSD systems in that the .\".BR chown (1) .\"and .\".BR chgrp (1) .\"commands follow symbolic links specified on the command line. La commande \fBfile\fP(1) est aussi une exception à cette règle. Par défaut, la commande \fBfile\fP(1) ne suit pas les liens symboliques fournis en argument. La commande \fBfile\fP(1) ne les suit que si l'option \fI\-L\fP est mentionnée. .SS "Commandes parcourant une arborescence" Les commandes suivantes parcourent, toujours ou sur option, l'arborescence des fichiers\ : \fBchgrp\fP(1), \fBchmod\fP(1), \fBchown\fP(1), \fBcp\fP(1), \fBdu\fP(1), \fBfind\fP(1), \fBls\fP(1), \fBpax\fP(1), \fBrm\fP(1) et \fBtar\fP(1). .PP 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. .PP La \fIpremière règle\fP 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. .PP La commande \fIrm\ \-r\ slink\ répertoire\fP effacera \fIslink\fP, ainsi que tout lien symbolique rencontré durant le parcours dans le \fIrépertoire\fP, car les liens symboliques peuvent être effacés. En aucun cas \fBrm\fP(1) ne touchera au fichier référencé par \fIslink\fP. .PP La \fIseconde règle\fP 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). .PP Certaines conventions sont (ou devraient être) respectées autant que possible par les commandes parcourant des arborescences de fichiers\ : .IP \[bu] 3 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 \fI\-H\fP (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 \fI\-H\fP sera ignorée si l'option \fI\-R\fP n'est pas également présente.) .IP Par exemple, la commande \fIchown\ \-HR\ utilisateur\ slink\fP parcourra la hiérarchie de fichiers débutant par le fichier pointé par \fIslink\fP. Remarquez que l'option \fI\-H\fP n'est pas la même que l'option \fI\-h\fP traitée précédemment. L'option \fI\-H\fP 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. .IP \[bu] 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 \fI\-L\fP (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 \fI\-L\fP si l'option \fI\-R\fP n'est pas présente. .IP Par exemple, la commande \fIchown\ \-LR\ utilisateur\ slink\fP modifiera le propriétaire du fichier référencé par \fIslink\fP. Si \fIslink\fP pointe vers un répertoire, \fBchown\fP(1) descendra l'arborescence à partir de ce répertoire. En outre, si des liens symboliques sont rencontrés pendant le parcours de \fBchown\fP(1), ils seront traités de la même façon que \fIslink\fP. .IP \[bu] Une commande peut être forcée à employer le comportement par défaut en utilisant l'option \fI\-P\fP (pour «\ physique\ »). Cet attribut permet de rendre l'espace de noms semblable à l'espace de noms physique. .PP Pour les commandes qui ne parcourent pas d'arborescence par défaut, les options \fI\-H\fP, \fI\-L\fP et \fI\-P\fP sont ignorées si l'option \fI\-R\fP n'est pas présente. De plus, vous pouvez indiquer \fI\-H\fP, \fI\-L\fP et \fI\-P\fP 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. .PP Les commandes \fBls\fP(1) et \fBrm\fP(1) présentent des exceptions pour ces règles\ : .IP \[bu] 3 La commande \fBrm\fP(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 \fBrm\fP(1) ne prend pas en charge les options \fI\-H\fP, \fI\-L\fP ou \fI\-P\fP. .IP \[bu] Afin d'assurer une compatibilité avec les systèmes historiques, la commande \fBls\fP(1) agit un peu différemment. Si une option \fI\-F\fP, \fI\-d\fP ou \fI\-l\fP n’est pas précisée, alors \fBls\fP(1) suivra les liens indiqués sur la ligne de commande. Si l'option \fI\-L\fP est mentionnée, \fBls\fP(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. .SH "VOIR AUSSI" \fBchgrp\fP(1), \fBchmod\fP(1), \fBfind\fP(1), \fBln\fP(1), \fBls\fP(1), \fBmv\fP(1), \fBnamei\fP(1), \fBrm\fP(1), \fBlchown\fP(2), \fBlink\fP(2), \fBlstat\fP(2), \fBreadlink\fP(2), \fBrename\fP(2), \fBsymlink\fP(2), \fBunlink\fP(2), \fButimensat\fP(2), \fBlutimes\fP(3), \fBpath_resolution\fP(7) .PP .SH TRADUCTION La traduction française de cette page de manuel a été créée par Christophe Blaess , Stéphan Rafin , Thierry Vignaud , François Micaux, Alain Portal , Jean-Philippe Guérard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas François , Florentin Duneau , Simon Paillard , Denis Barbier , David Prévot , Frédéric Hantrais et Jean-Paul Guillonneau . .PP Cette traduction est une documentation libre ; veuillez vous reporter à la .UR https://www.gnu.org/licenses/gpl-3.0.html GNU General Public License version 3 .UE concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE. .PP Si vous découvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message à .MT debian-l10n-french@lists.debian.org .ME .