Provided by: manpages-fr_4.18.1-1_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 :

       •  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).

   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).

       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.

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

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