symlink(7) Miscellaneous Information Manual symlink(7) 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 reference directe vers l'objet sous-jacent pointe par le nom originel. (Pour etre precis, chaque lien physique sur un fichier fait reference au meme numero d'inoeud, ce numero etant un indice dans une table d'inoeuds qui contient des metadonnees sur tout le contenu du systeme de fichiers. Consultez stat(2)). Les changements dans un fichier sont independants du nom utilise pour faire reference au fichier. Les liens physiques ne peuvent pas faire reference aux repertoires (pour eviter le risque de boucles dans l'arborescence du systeme de fichiers, ce qui planterait de nombreux programmes) et ne peuvent pas referencer des fichiers sur un autre systeme de fichiers (car les numeros d'inoeud ne sont uniques que sur un meme systeme de fichiers). Un lien symbolique est un fichier d'un type special, dont le contenu est une chaine representant le chemin d'acces vers un autre fichier, celui vers lequel le lien pointe. (Le contenu d'un lien symbolique peut etre 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 reference aux repertoires et peuvent franchir les frontieres des systemes de fichiers. Il n'y a pas d'obligation pour que le fichier dont le nom est reference par un lien symbolique existe. Un lien symbolique qui fait reference a un nom de fichier inexistant est dit dangling link (pendouillant). Comme un lien symbolique et l'objet qu'il reference coexistent sur le systeme de fichiers, une confusion peut survenir pour distinguer le lien lui-meme et l'objet reference. Sur des systemes historiques, les commandes et les appels systeme adoptaient leur propres conventions pour le suivi des liens symboliques de maniere arbitraire. Des regles pour une approche plus uniforme, comme elles sont implementees sur Linux et d'autres systemes, sont presentees ici. Il est important que les applications locales se conforment aussi a ces regles pour que l'interface avec l'utilisateur soit la plus coherente possible. Liens magiques Il existe une classe speciale d'objets ressemblant aux liens symboliques connus comme << liens magiques >> qui peuvent etre trouves dans certains pseudo-systemes 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 resolus au travers d'une expansion de noms de chemin, mais agissent plutot comme des references directes vers la propre representation du noyau de la gestion de fichier. Comme tels, ces liens magiques permettent aux utilisateurs d'acceder a des fichiers qui ne peuvent etre references par des chemins normaux (tels que des fichiers delies encore references par un programme en cours d'execution). Parce qu'ils peuvent contourner les restrictions ordinaires basees sur mount_namespaces(7), les liens magiques ont ete utilises comme vecteur d'attaque dans divers exploits. Proprietes, permissions et horodatage des liens symboliques Le proprietaire et le groupe d'un lien symbolique existant peuvent etre modifies en utilisant lchown(2). L'appartenance d'un lien symbolique est importante lors de sa suppression ou de son renommage dans un repertoire dont le bit << Sticky >> est positionne (consultez inode(7)) et quand le sysctl fs.protected_symlinks est defini (see proc(5)). Les horodatages du dernier acces et de la derniere modification d'un lien symbolique peuvent etre modifies en utilisant utimensat(2) ou lutimes(3). Sur Linux, les permissions associees a un lien symbolique ordinaire ne sont utilisees dans aucune operation. Ces permissions sont toujours 0777 (lecture, ecriture et execution pour toutes les categories d'utilisateurs) et ne peuvent pas etre modifiees. Cependant, les liens magiques ne suivent pas cette regle. Ils peuvent avoir un mode different de 0777, bien que ce mode ne soit pas actuellement utilise pour la verification des permissions. Obtention d'un descripteur de fichier faisant reference a un lien symbolique. L'utilisation des indicateurs O_PATH et O_NOFOLLOW en association pour un appel open(2) delivre un descripteur de fichier qui peut etre transmis comme l'argument dirfd a des appels systeme tels que fstatat(2), fchownat(2), fchmodat(2), linkat(2) et readlinkat(2), afin d'agir sur des liens symboliques eux-memes (et non sur les fichiers vers lesquels ils pointent). Par defaut (c'est-a-dire si l'indicateur AT_SYMLINK_FOLLOW n'est pas precise), lorsque name_to_handle_at(2) est utilisee sur un lien symbolique, il delivre 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 precisant l'indicateur O_PATH lors d'un appel ulterieur a open_by_handle_at(2). De nouveau, ce descripteur de fichier peut etre utilise dans des appels systeme cites precedemment pour agir sur le lien symbolique lui-meme. Traitement des liens symboliques par les appels systeme et les commandes Les liens symboliques sont traites en agissant soit sur le lien lui-meme, soit sur l'objet pointe par le lien. Dans ce dernier cas, on dit que l'application ou l'appel systeme suit le lien. Les liens symboliques peuvent faire reference a d'autres liens symboliques, auquel cas les liens sont suivis jusqu'a ce qu'un objet qui n'est pas un lien symbolique soit rencontre, qu'un lien symbolique pointant sur un fichier inexistant soit trouve, ou qu'une boucle soit detectee (la detection des boucles est faite en definissant une limite maximale sur le nombre de liens qui peuvent etre suivis, et une erreur se produit si cette limite est atteinte). Il faut considerer trois domaines d'utilisation differents des liens symboliques. Ce sont : - Les liens symboliques fournis en argument des appels systeme sous forme de noms de fichiers. - Les liens symboliques indiques comme arguments de la ligne de commande pour les utilitaires qui ne parcourent pas l'arborescence des fichiers. - Les liens symboliques rencontres par les utilitaires qui traversent l'arborescence (soit indiques sur la ligne de commande, soit rencontres comme partie de la hierarchie des fichiers). Avant de decrire le traitement des liens symboliques par les appels systeme et les commandes, quelques explications technologiques sont necessaires. Etant donne un nom de chemin de la forme a/b/c, la partie precedant la barre oblique finale (c'est-a-dire a/b) est appelee la composante dirname (nom de repertoire) et la partie suivant la barre oblique finale (c'est-a-dire c) est appelee la composante basename (nom de base). Traitement des liens symboliques par les appels systeme Le premier domaine est celui des liens symboliques utilises en noms de fichiers comme argument pour les appels systeme. Le traitement des liens symboliques dans un nom de chemin passe a un appel systeme est le suivant : (1) Dans la composante du nom de repertoire d'un chemin, les liens symboliques sont toujours suivis dans presque tous les appels systeme (cela est aussi vrai pour les commandes). La seule exception est openat2(2) qui fournit des indicateurs pouvant etre utilises pour empecher explicitement le suivi de liens symboliques dans la composante du nom de repertoire. (2) Sauf exceptions mentionnees ci-dessous, tous les appels systeme 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 appele un_fichier, l'appel systeme open("slink" ...) renverra un descripteur de fichier faisant reference a un_fichier. Certains appels systeme ne suivent pas les liens symboliques dans la composante du nom de base d'un chemin et agissent sur le lien symbolique lui-meme. 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 systeme suivent eventuellement 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 a leur pages de manuel pour plus de details. Comme remove(3) est un alias pour unlink(2), cette fonction de bibliotheque ne suit pas non plus les liens symboliques. Quand rmdir(2) est utilisee sur un lien symbolique, elle echoue avec l'erreur ENOTDIR. L'appel link(2) reclame une discussion particuliere. POSIX.1-2001 precise que link(2) doit dereferencer ancien_chemin si c'est un lien symbolique. Neanmoins, Linux ne le fait pas. (Par defaut, Solaris non plus, mais des options de compilation permettent d'obtenir le comportement POSIX.1-2001). POSIX.1-2008 a modifie la specification pour permettre les deux comportements dans une implementation. Commandes ne parcourant pas les arborescences de fichiers Le second domaine est celui des liens symboliques, indiques en tant que noms de fichiers, comme argument pour des commandes ne traversant pas les arborescences. Sauf exception mentionnee 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 nomme un_fichier, la commande cat slink affichera le contenu du fichier un_fichier. Notez bien que cette regle s'applique a des commandes qui peuvent dans d'autres situations parcourir l'arborescence, par exemple la commande chown fichier suit cette regle, alors que chown -R fichier, qui descend l'arborescence, ne la suit pas. (Cette derniere est traitee dans la troisieme partie ci-dessous). Si on desire qu'une commande agisse sur le lien symbolique lui-meme plutot qu'en le suivant -- par exemple si on veut que chown slink change le proprietaire du fichier slink, que ce soit un lien symbolique ou non -- l'option -h doit etre utilisee. Dans cet exemple, la commande chown root slink modifierait le proprietaire du fichier reference par slink, tandis que chown -h root slink modifierait le proprietaire de slink lui-meme. Il y a quelques exceptions a cette regle : - 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 detruire. (Notez que lorsqu'un lien symbolique fait reference a un fichier par un chemin relatif, il peut cesser de fonctionner si on le deplace dans un autre repertoire puisque le chemin relatif ne serait plus correct). - La commande ls(1) est aussi une exception a cette regle. Pour assurer la compatibilite avec des systemes historiques (quand ls(1) ne descend pas une arborescence -- c'est-a-dire si l'option -R n'est pas presente), la commande ls(1) suit les liens symboliques fournis en argument si les options -H ou -L sont indiquees ou si les options -F, -d et -l ne sont pas presentes (la commande ls(1) est la seule dont les options -H et -L modifient le comportement meme lorsqu'elle ne fait pas un parcours d'arborescence). - La commande file(1) est aussi une exception a cette regle. Par defaut, 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 mentionnee. 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 regles ci-dessous s'appliquent tant aux liens symboliques rencontres durant un parcours d'arborescence qu'aux liens fournis en argument de ligne de commande. La premiere regle s'applique aux liens qui referencent des fichiers autres que des repertoires. Les operations entreprises sur ces liens sont appliquees sur les liens eux-memes, ou alors les liens sont ignores. La commande rm -r slink repertoire effacera slink, ainsi que tout lien symbolique rencontre durant le parcours dans le repertoire, car les liens symboliques peuvent etre effaces. En aucun cas rm(1) ne touchera au fichier reference par slink. La seconde regle s'applique aux liens symboliques qui pointent vers des repertoires. Par defaut, ces liens ne sont jamais suivis. Cela est souvent appele un parcours << physique >> par opposition a un parcours << logique >> (ou les liens symboliques vers des repertoires seraient suivis). Certaines conventions sont (ou devraient etre) respectees autant que possible par les commandes parcourant des arborescences de fichiers : - Une commande peut etre forcee a suivre n'importe quel lien symbolique indique 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 a l'espace de noms logique. (Notez que pour les commandes qui ne parcourent pas toujours l'arborescence, l'option -H sera ignoree si l'option -R n'est pas egalement presente.) Par exemple, la commande chown -HR utilisateur slink parcourra la hierarchie de fichiers debutant par le fichier pointe par slink. Remarquez que l'option -H n'est pas la meme que l'option -h traitee precedemment. L'option -H permet de suivre les liens symboliques indiques sur la ligne de commande aussi bien pour l'action a executer que pour le parcours de l'arborescence ; tout se passe comme si l'utilisateur avait fourni le nom du fichier reference par le lien symbolique. - Une commande peut etre forcee a suivre les liens symboliques nommes sur sa ligne de commande, ainsi que tous les liens rencontres durant le parcours, quel que soit le type des fichiers qu'ils referencent, en utilisant l'option -L (pour << logical >>). Cette option permet de rendre l'espace de noms en entier semblable a l'espace de noms logique. Notez que les commandes qui ne font pas systematiquement de parcours d'arborescence ignoreront l'option -L si l'option -R n'est pas presente. Par exemple, la commande chown -LR utilisateur slink modifiera le proprietaire du fichier reference par slink. Si slink pointe vers un repertoire, chown(1) descendra l'arborescence a partir de ce repertoire. En outre, si des liens symboliques sont rencontres pendant le parcours de chown(1), ils seront traites de la meme facon que slink. - Une commande peut etre forcee a employer le comportement par defaut en utilisant l'option -P (pour << physique >>). Cet attribut permet de rendre l'espace de noms semblable a l'espace de noms physique. Pour les commandes qui ne parcourent pas d'arborescence par defaut, les options -H, -L et -P sont ignorees si l'option -R n'est pas presente. De plus, vous pouvez indiquer -H, -L et -P plusieurs fois ; c'est la derniere option qui determinera le comportement de la commande. Cela permet de creer 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) presentent des exceptions pour ces regles : - La commande rm(1) agit toujours sur le lien symbolique et jamais sur le fichier qu'il reference. 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 compatibilite avec les systemes historiques, la commande ls(1) agit un peu differemment. Si une option -F, -d ou -l n'est pas precisee, alors ls(1) suivra les liens indiques sur la ligne de commande. Si l'option -L est mentionnee, ls(1) suivra tous les liens symboliques, quels que soient leurs types, qu'ils soient fournis sur la ligne de commande ou rencontres 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) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot , Frederic Hantrais et Jean- Paul Guillonneau Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.12 2 mai 2024 symlink(7)