NOM

       path_resolution - Trouver le fichier auquel un chemin fait référence

DESCRIPTION

       Certains appels système UNIX/Linux ont pour paramètre un ou plusieurs noms de fichiers. Un
       nom de fichier (ou chemin) est résolu de la manière suivante.

   Étape 1 : Démarrer le processus de résolution
       If the pathname starts with the '/' character, the starting lookup directory is  the  root
       directory  of  the calling process. A process inherits its root directory from its parent.
       Usually this will be the root directory of  the  file  hierarchy.  A  process  may  get  a
       different  root  directory  by use of the chroot(2)  system call, or may temporarily use a
       different root directory by using openat2(2)  with the RESOLVE_IN_ROOT flag set.

       A process may get an entirely private mount namespace in case it—or one of its  ancestors—
       was  started  by  an invocation of the clone(2)  system call that had the CLONE_NEWNS flag
       set. This handles the '/' part of the pathname.

       If the pathname does not start with the '/' character, the starting  lookup  directory  of
       the resolution process is the current working directory of the process — or in the case of
       openat(2)-style system calls, the dfd  argument  (or  the  current  working  directory  if
       AT_FDCWD  is  passed as the dfd argument). The current working directory is inherited from
       the parent, and can be changed by use of the chdir(2)  system call.

       Les chemins débutant avec le caractère « / » sont appelés chemins absolus. Les chemins  ne
       débutant pas avec le caractère « / » sont appelés chemins relatifs.

   Étape 2 : Se promener le long du chemin
       Le  répertoire de recherche courant est le répertoire de recherche de départ. On appellera
       composant d'un chemin une sous-chaîne délimitée par des caractères « / ». Chaque composant
       du  chemin  qui n'est pas le composant final est recherché dans le répertoire de recherche
       courant.

       Si le processus n'a pas les permissions nécessaires pour effectuer la  recherche  dans  le
       répertoire  de  recherche courant, une erreur EACCES est renvoyée (« Permission denied » :
       « Permission non accordée »).

       Si le composant n'est pas trouvé, une erreur  ENOENT  est  renvoyée  (« No  such  file  or
       directory » : « Aucun fichier ou répertoire de ce type »).

       Si  le composant est trouvé mais que ce n'est ni un répertoire, ni un lien symbolique, une
       erreur ENOTDIR est renvoyée (« Not a directory » : « N'est pas un répertoire »).

       Si le composant est trouvé et que c'est un répertoire, le répertoire de recherche  courant
       devient ce répertoire et on passe au composant suivant.

       If the component is found and is a symbolic link (symlink), we first resolve this symbolic
       link (with the current lookup directory as starting lookup directory).  Upon  error,  that
       error  is returned. If the result is not a directory, an ENOTDIR error is returned. If the
       resolution of the symbolic link is successful and returns a directory, we set the  current
       lookup directory to that directory, and go to the next component. Note that the resolution
       process here can involve recursion if the  prefix  ('dirname')  component  of  a  pathname
       contains a filename that is a symbolic link that resolves to a directory (where the prefix
       component of that directory may contain a symbolic link, and so on). In order  to  protect
       the  kernel  against  stack overflow, and also to protect against denial of service, there
       are limits on the maximum recursion depth, and on the maximum  number  of  symbolic  links
       followed.  An  ELOOP  error  is returned when the maximum is exceeded ("Too many levels of
       symbolic links").

       As currently implemented on Linux, the maximum number  of  symbolic  links  that  will  be
       followed  while  resolving  a  pathname  is 40. In kernels before 2.6.18, the limit on the
       recursion depth was 5. Starting with Linux 2.6.18, this limit was raised to  8.  In  Linux
       4.2, the kernel's pathname-resolution code was reworked to eliminate the use of recursion,
       so that the only limit that remains is the  maximum  of  40  resolutions  for  the  entire
       pathname.

       The  resolution  of  symbolic  links during this stage can be blocked by using openat2(2),
       with the RESOLVE_NO_SYMLINKS flag set.

   Étape 3 : Trouver l'entrée finale
       La recherche du dernier composant du nom de chemin s'effectue de la même manière  que  les
       autres  composants,  comme  décrit dans l'étape précédente, avec deux différences : (i) le
       composant final n'a pas besoin d'être un répertoire (du moins tant  que  le  processus  de
       résolution du chemin est concerné — il peut être ou ne pas être un répertoire, suivant les
       exigences de l'appel système concerné), et (ii) ce n'est peut-être pas une  erreur  si  le
       composant  n'est  pas  trouvé  —  peut-être  vient  on  juste  de le créer. Les détails du
       traitement du composant final sont décrits dans les pages de  manuel  des  appels  système
       concernés.

   . et ..
       Par  convention,  chaque  répertoire  possède  les  entrées  .  et  .., qui se rapportent,
       respectivement, au répertoire lui-même et à son répertoire parent.

       Le  processus  de  résolution  de  chemin  considère  que  ces  entrées  ont  leurs   sens
       conventionnels, sans considération de leur existence ou non sur le système de fichiers.

       One cannot walk up past the root: "/.." is the same as "/".

   Points de montage
       Après  une commande mount périphérique chemin, le nom de chemin chemin fait référence à la
       racine de la hiérarchie du système de fichiers sur le périphérique, et  plus  du  tout  ce
       qu'il référençait précédemment.

       On  peut  sortir  d'un  système de fichiers monté : chemin/.. fait référence au répertoire
       parent de chemin, en dehors de la hiérarchie du système de fichiers sur périphérique.

       Traversal of mount points can be blocked by using  openat2(2),  with  the  RESOLVE_NO_XDEV
       flag set (though note that this also restricts bind mount traversal).

   Barres obliques de fin
       If  a pathname ends in a '/', that forces resolution of the preceding component as in Step
       2: the component preceding the slash either exists and resolves to a directory or it names
       a directory that is to be created immediately after the pathname is resolved. Otherwise, a
       trailing '/' is ignored.

   Lien symbolique final
       Si le dernier composant d'un nom de chemin est un lien symbolique, cela dépend de  l'appel
       système  si  le  fichier  référencé  sera  le  lien  symbolique  ou bien le résultat de la
       résolution de chemin sur son contenu. Par exemple, l'appel système lstat(2)  agit  sur  le
       lien symbolique alors que stat(2) agit sur le fichier pointé par le lien.

   Limite de longueur
       Il  y  a  une  longueur  maximum  pour  les  noms  de  chemins. Si le chemin (ou un chemin
       intermédiaire  obtenu  en  résolvant  un  lien  symbolique)  est  trop  long,  une  erreur
       ENAMETOOLONG est renvoyée (« Filename too long » : « Nom de fichier trop long »).

   Nom de chemin vide
       Dans  l'UNIX  d'origine,  un  nom  de chemin vide faisait référence au répertoire courant.
       Aujourd'hui, POSIX décrète qu'un nom de fichier vide ne doit pas être résolu avec  succès.
       Linux renvoie ENOENT dans ce cas.

   Permissions
       The  permission  bits  of  a file consist of three groups of three bits; see chmod(1)  and
       stat(2). The first group of three is used when  the  effective  user  ID  of  the  calling
       process  equals the owner ID of the file. The second group of three is used when the group
       ID of the file either equals the effective group ID of the calling process, or is  one  of
       the  supplementary group IDs of the calling process (as set by setgroups(2)). When neither
       holds, the third group is used.

       Des trois bits utilisés, le premier détermine la permission de  lecture,  le  deuxième  la
       permission  d'écriture  et  le  dernier la permission d'exécution dans le cas d'un fichier
       ordinaire ou la permission de recherche dans le cas d'un répertoire.

       Linux utilise le fsuid  à  la  place  de  l'UID  effectif  lors  de  la  vérification  des
       permissions.  D'ordinaire,  le  fsuid  est  égal à l'UID effectif, mais le fsuid peut être
       modifié avec l'appel système setfsuid(2).

       (Ici, « fsuid » signifie quelque chose comme « UID  système  de  fichiers »  (« filesystem
       user  ID »).  Le  concept  était  requis  pour l'implémentation d'un serveur NFS en espace
       utilisateur au moment où les processus pouvaient envoyer un  signal  à  un  processus  qui
       avait le même UID effectif. Il est aujourd'hui obsolète. Personne ne devrait plus utiliser
       setfsuid(2).)

       De la même manière, Linux  utilise  le  fsgid  à  la  place  du  GID  effectif.  Consultez
       setfsgid(2).

   Contourner les vérifications de permissions : superutilisateur et capacités
       Sur  un  système  UNIX  traditionnel,  le  superutilisateur  (root,  d'identifiant  0) est
       tout-puissant, et shunte toutes les restrictions de permissions  lorsqu'il  accède  à  des
       fichiers.

       Sous  Linux,  les  privilèges  du  superutilisateur  sont  divisés en capacités (consultez
       capabilities(7)).  Deux  de  ces  capacités  sont  liées  aux  vérifications  d'accès  aux
       fichiers :  CAP_DAC_OVERRIDE  et CAP_DAC_READ_SEARCH. (Un processus a ces capacités si son
       fsuid est 0.)

       La capacité CAP_DAC_OVERRIDE écrase toutes les vérifications de permission mais n'assurera
       la permission d'exécution que si au moins un des trois bits d'exécution est à 1.

       La  capacité CAP_DAC_READ_SEARCH assurera la permission de lecture et de recherche sur les
       répertoires, et la permission de lecture sur les fichiers ordinaires.

VOIR AUSSI

       readlink(2), capabilities(7), credentials(7), symlink(7)

COLOPHON

       Cette page fait partie de la publication 5.13 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> et David Prévot <david@tilapin.org>

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