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

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