Provided by: manpages-fr_3.23.1-1_all bug

NOM

       Résolution de chemin sous Unix/Linux - Trouver le fichier référencé par
       son nom

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   non   accordée »,  Ndt :  « Permission
       denied »).

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

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

       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 (« Trop de niveaux de liens symboliques »,  Ndt :  « Too  many
       levels of symbolic links »).

   Étape 3 : Trouver lentré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 (« Nom de fichier trop
       long », Ndt : « File name too 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 »  (Ndt :  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.
       Voir 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 (voir 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

       capabilities(7), credentials(7), symlink(7)

COLOPHON

       Cette  page  fait  partie  de  la  publication 3.23 du projet man-pages
       Linux. Une description du projet et des instructions pour signaler  des
       anomalies       peuvent       être       trouvées      à      l’adresse
       http://www.kernel.org/doc/man-pages/.

TRADUCTION

       Cette page de manuel a été traduite et mise à  jour  par  Alain  Portal
       <aportal  AT  univ-montp2  DOT  fr>  entre  2004  et  2006,  et  mise à
       disposition sur http://manpagesfr.free.fr/.

       Les mises à jour et corrections de la version présente dans Debian sont
       directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
       francophone de traduction de Debian.

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