Provided by: manpages-fr_3.32d0.2p4-1_all bug

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
       Si le chemin débute avec le caractère « / », le répertoire de recherche
       de départ est le répertoire racine du processus appelant. (Un processus
       hérite  son  répertoire  racine  de  son père. Habituellement, c'est le
       répertoire racine de la hiérarchie  des  fichiers.  Un  processus  peut
       avoir  un  répertoire  racine  différent  avec l'utilisation de l'appel
       système chroot(2). Un  processus  peut  récupérer  un  espace  noms  de
       montage  privé entier dans le cas où lui — ou un de ses parents — a été
       démarré par une invocation de l'appel système clone(2) avec  l'attribut
       CLONE_NEWNS positionné.) Cela gère la partie « / » du chemin.

       Si  le  chemin  ne  débute pas par le caractère « / », le répertoire de
       recherche de départ  du  processus  de  résolution  est  le  répertoire
       courant  du  processus.  (Lui  aussi  est  hérité du père. Il peut être
       modifié avec l'appel système chdir(2).)

       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.

       Si le composant est trouvé et que c'est un lien symbolique,  on  résout
       d'abord  ce  lien  (avec  le  répertoire  de  recherche  courant  comme
       répertoire de recherche de  départ).  Si  une  erreur  survient,  cette
       erreur  est  renvoyée.  Si  le  résultat  de la résolution n'est pas un
       répertoire, une erreur ENOTDIR est renvoyée. Si la résolution  du  lien
       symbolique  est  couronnée  de  succès  et  renvoie  un  répertoire, le
       répertoire de recherche courant devient ce répertoire et  on  passe  au
       composant  suivant.  Veuillez  noter  que  le  processus  de résolution
       implique une récursivité. Afin de protéger le noyau d'un débordement de
       pile  et  également  d'un  déni  de  service,  il  y a des limites à la
       profondeur maximum de récursivité  et  aux  nombres  maximum  de  liens
       symboliques  suivis. Une erreur ELOOP est renvoyée lors ces maxima sont
       atteints (« Too many levels of symbolic links » : « Trop de niveaux  de
       liens symboliques »).

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

       On ne peut plus sortir passée la racine : /.. est identique à /.

   Points de montage
       Après une commande mount priphrique chemin, le nom de  chemin  chemin
       fait  référence à la racine de la hiérarchie du système de fichiers sur
       le priphrique, 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 priphrique.

   Barres obliques de fin
       Si un nom de chemin finit avec un « / », cela force  la  résolution  du
       composant  qui  le  précède  comme décrit dans l'étape 2 — le composant
       doit exister et être résolu comme répertoire. Autrement, un « / » final
       est  ignoré. (Ou bien, de manière équivalente, un nom de chemin avec un
       « / » final est équivalent au nom de chemin obtenu en ajoutant « . »  à
       la fin.)

   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  (« File name 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
       Les  bits  de  permissions  d'un fichier consistent en trois groupes de
       trois bits, cf. chmod(1) et stat(2). Le  premier  de  ces  groupes  est
       utilisé  lorsque  l'UID effectif du processus appelant est égal à l'UID
       réel (le propriétaire) du fichier.  Le  deuxième  de  ces  groupes  est
       utilisé  lorsque  le  GID  du  fichier est soit égal au GID effectif du
       processus appelant, soit est un des GID  supplémentaires  du  processus
       appelant   (comme   configuré   avec   setgroups(2)).  Lorsqu'aucun  ne
       correspond, le troisième groupe est utilisé.

       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 »  (« file  system  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 3.32 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       être       trouvées      à      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue à l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'équipe   de   traduction
       francophone       au       sein        du        projet        perkamon
       <URL:http://perkamon.alioth.debian.org/>.

       Alain   Portal   <URL:http://manpagesfr.free.fr/> (2004-2006).   Julien
       Cristau et l'équipe francophone de traduction de Debian (2006-2009).

       Veuillez  signaler  toute  erreur   de   traduction   en   écrivant   à
       <debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
       paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de  ce  document
       en utilisant la commande « man -L C <section> <page_de_man> ».