Provided by: manpages-fr_4.13-4_all bug

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 ⟨⟩.