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

NOM

       path_resolution - Trouver le fichier auquel un chemin fait reference

DESCRIPTION

       Certains  appels  systeme UNIX/Linux ont pour parametre un ou plusieurs
       noms de fichiers. Un nom de  fichier  (ou  chemin)  est  resolu  de  la
       maniere suivante.

   'Etape 1 : D'emarrer le processus de r'esolution
       Si  le  chemin  debute  avec  le  caractere  << / >>,  le repertoire de
       recherche de depart est le repertoire racine du processus appelant. (Un
       processus  herite  son  repertoire  racine de son pere. Habituellement,
       c'est le repertoire racine de la hierarchie des fichiers. Un  processus
       peut avoir un repertoire racine different avec l'utilisation de l'appel
       systeme chroot(2). Un  processus  peut  recuperer  un  espace  noms  de
       montage  prive  entier  dans le cas ou lui -- ou un de ses parents -- a
       ete demarre  par  une  invocation  de  l'appel  systeme  clone(2)  avec
       l'attribut  CLONE_NEWNS  positionne.)  Cela  gere  la partie << / >> du
       chemin.

       Si le chemin ne debute pas par le caractere << / >>, le  repertoire  de
       recherche  de  depart  du  processus  de  resolution  est le repertoire
       courant du processus. (Lui aussi est  herite  du  pere.  Il  peut  etre
       modifie avec l'appel systeme chdir(2).)

       Les  chemins  debutant  avec  le caractere << / >> sont appeles chemins
       absolus. Les chemins ne debutant pas avec  le  caractere  << / >>  sont
       appeles chemins relatifs.

   'Etape 2 : Se promener le long du chemin
       Le  repertoire  de  recherche courant est le repertoire de recherche de
       depart. On appellera composant d'un chemin  une  sous-chaine  delimitee
       par des caracteres << / >>. Chaque composant du chemin qui n'est pas le
       composant final est recherche dans le repertoire de recherche courant.

       Si le processus n'a pas les permissions necessaires pour  effectuer  la
       recherche  dans  le  repertoire de recherche courant, une erreur EACCES
       est renvoyee (<< Permission denied >> : << Permission non accordee >>).

       Si le composant n'est pas trouve, une erreur ENOENT est renvoyee (<< No
       such  file  or  directory >> :  << Aucun  fichier  ou  repertoire de ce
       type >>).

       Si le composant est trouve mais que ce n'est ni un  repertoire,  ni  un
       lien   symbolique,   une   erreur   ENOTDIR   est  renvoyee  (<< Not  a
       directory >> : << N'est pas un repertoire >>).

       Si le composant est trouve et que c'est un repertoire, le repertoire de
       recherche  courant  devient  ce  repertoire  et  on  passe au composant
       suivant.

       Si le composant est trouve et que c'est un lien symbolique,  on  resout
       d'abord  ce  lien  (avec  le  repertoire  de  recherche  courant  comme
       repertoire de recherche de  depart).  Si  une  erreur  survient,  cette
       erreur  est  renvoyee.  Si  le  resultat  de la resolution n'est pas un
       repertoire, une erreur ENOTDIR est renvoyee. Si la resolution  du  lien
       symbolique  est  couronnee  de  succes  et  renvoie  un  repertoire, le
       repertoire de recherche courant devient ce repertoire et  on  passe  au
       composant  suivant.  Veuillez  noter  que  le  processus  de resolution
       implique une recursivite. Afin de proteger le noyau d'un debordement de
       pile  et  egalement  d'un  deni  de  service,  il  y a des limites a la
       profondeur maximum de recursivite  et  aux  nombres  maximum  de  liens
       symboliques  suivis. Une erreur ELOOP est renvoyee lors ces maxima sont
       atteints (<< Too many levels of symbolic links >> : << Trop de  niveaux
       de liens symboliques >>).

   'Etape 3 : Trouver l'entr'ee finale
       La  recherche  du  dernier  composant du nom de chemin s'effectue de la
       meme maniere que les  autres  composants,  comme  decrit  dans  l'etape
       precedente,  avec  deux  differences :  (i)  le composant final n'a pas
       besoin d'etre  un  repertoire  (du  moins  tant  que  le  processus  de
       resolution  du  chemin  est  concerne -- il peut etre ou ne pas etre un
       repertoire, suivant les exigences de l'appel systeme concerne), et (ii)
       ce  n'est  peut-etre pas une erreur si le composant n'est pas trouve --
       peut-etre vient on juste de le creer.  Les  details  du  traitement  du
       composant  final  sont  decrits  dans  les  pages  de manuel des appels
       systeme concernes.

   . et ..
       Par convention, chaque repertoire possede les entrees . et ..,  qui  se
       rapportent,  respectivement, au repertoire lui-meme et a son repertoire
       parent.

       Le processus de resolution de chemin  considere  que  ces  entrees  ont
       leurs  sens conventionnels, sans consideration de leur existence ou non
       sur le systeme de fichiers.

       On ne peut plus sortir passee la racine : /.. est identique a /.

   Points de montage
       Apres une commande mount p'eriph'erique chemin, le nom de  chemin  chemin
       fait  reference a la racine de la hierarchie du systeme de fichiers sur
       le p'eriph'erique, et plus du tout ce qu'il referencait precedemment.

       On  peut  sortir  d'un  systeme  de  fichiers  monte :  chemin/..  fait
       reference au repertoire parent de chemin, en dehors de la hierarchie du
       systeme de fichiers sur p'eriph'erique.

   Barres obliques de fin
       Si un nom de chemin finit avec un << / >>, cela force la resolution  du
       composant  qui  le  precede comme decrit dans l'etape 2 -- le composant
       doit exister et etre resolu comme  repertoire.  Autrement,  un  << / >>
       final  est  ignore.  (Ou bien, de maniere equivalente, un nom de chemin
       avec un << / >> final  est  equivalent  au  nom  de  chemin  obtenu  en
       ajoutant << . >> a la fin.)

   Lien symbolique final
       Si le dernier composant d'un nom de chemin est un lien symbolique, cela
       depend de  l'appel  systeme  si  le  fichier  reference  sera  le  lien
       symbolique  ou  bien  le  resultat  de  la resolution de chemin sur son
       contenu. Par  exemple,  l'appel  systeme  lstat(2)  agit  sur  le  lien
       symbolique alors que stat(2) agit sur le fichier pointe par le lien.

   Limite de longueur
       Il  y a une longueur maximum pour les noms de chemins. Si le chemin (ou
       un chemin intermediaire obtenu en resolvant  un  lien  symbolique)  est
       trop  long,  une  erreur  ENAMETOOLONG  est  renvoyee (<< File name too
       long >> : << Nom de fichier trop long >>).

   Nom de chemin vide
       Dans l'UNIX d'origine, un nom  de  chemin  vide  faisait  reference  au
       repertoire  courant.  Aujourd'hui,  POSIX  decrete qu'un nom de fichier
       vide ne doit pas etre resolu avec succes. 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
       utilise  lorsque  l'UID effectif du processus appelant est egal a l'UID
       reel (le proprietaire) du fichier.  Le  deuxieme  de  ces  groupes  est
       utilise  lorsque  le  GID  du  fichier est soit egal au GID effectif du
       processus appelant, soit est un des GID  supplementaires  du  processus
       appelant   (comme   configure   avec   setgroups(2)).  Lorsqu'aucun  ne
       correspond, le troisieme groupe est utilise.

       Des trois bits utilises, le premier determine la permission de lecture,
       le  deuxieme  la  permission  d'ecriture  et  le  dernier la permission
       d'execution dans le cas d'un fichier  ordinaire  ou  la  permission  de
       recherche dans le cas d'un repertoire.

       Linux  utilise  le  fsuid  a  la  place  de  l'UID  effectif lors de la
       verification des permissions. D'ordinaire, le fsuid est  egal  a  l'UID
       effectif,  mais  le  fsuid  peut  etre  modifie  avec  l'appel  systeme
       setfsuid(2).

       (Ici, << fsuid >>  signifie  quelque  chose  comme  << UID  systeme  de
       fichiers >>  (<< file  system user ID >>). Le concept etait requis pour
       l'implementation d'un serveur NFS en espace utilisateur  au  moment  ou
       les  processus  pouvaient envoyer un signal a un processus qui avait le
       meme UID effectif. Il est aujourd'hui  obsolete.  Personne  ne  devrait
       plus utiliser setfsuid(2).)

       De  la meme maniere, Linux utilise le fsgid a la place du GID effectif.
       Consultez setfsgid(2).

   Contourner les v'erifications de permissions : superutilisateur et capacit'es
       Sur  un  systeme  UNIX   traditionnel,   le   superutilisateur   (root,
       d'identifiant  0)  est tout-puissant, et shunte toutes les restrictions
       de permissions lorsqu'il accede a des fichiers.

       Sous  Linux,  les  privileges  du  superutilisateur  sont  divises   en
       capacites (consultez capabilities(7)). Deux de ces capacites sont liees
       aux  verifications   d'acces   aux   fichiers :   CAP_DAC_OVERRIDE   et
       CAP_DAC_READ_SEARCH. (Un processus a ces capacites si son fsuid est 0.)

       La   capacite  CAP_DAC_OVERRIDE  ecrase  toutes  les  verifications  de
       permission mais n'assurera la permission d'execution que si au moins un
       des trois bits d'execution est a 1.

       La capacite CAP_DAC_READ_SEARCH assurera la permission de lecture et de
       recherche sur les repertoires, 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       etre       trouvees      a      l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis 2010, cette traduction est maintenue a l'aide  de  l'outil  po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

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

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.

Linux                           5 decembre 2009             PATH_RESOLUTION(7)