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 fichier. 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 par 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
       parent. 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) ou peut temporairement utiliser un  répertoire  racine  différent  en  utilisant
       openat2(2) avec l’attribut RESOLVE_IN_ROOT défini.

       Un  processus  peut obtenir un espace de noms montage complètement privé dans le cas ou il
       — ou un de ses ancêtres — a été démarré par une invocation  de  l’appel  système  clone(2)
       dont l’attribut CLONE_NEWNS est défini. 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 — ou dans  le  cas  d’appel
       système  du  style  openat(2),  l’argument  dfd  (ou  le  répertoire courant de travail si
       AT_FDCWD est passé en tant qu’argument dfd). Le répertoire courant de travail  est  hérité
       du parent et peut être modifié avec l'appel système chdir(2).

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

   Étape 2 : parcourir le chemin
       Définir le répertoire courant de recherche au répertoire de démarrage de  recherche.  Puis
       pour  chaque  composant  non  terminal  du  chemin,  où  un  composant est une sous-chaine
       délimitée par des caractères « / », ce composant est recherché dans le répertoire  courant
       de recherche.

       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 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  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 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 peut impliquer une récursivité si le composant préfixe (« dirname ») du  chemin
       contient  un  nom  de  fichier  qui est un lien symbolique qui mène à un répertoire (où le
       composant préfixe de ce répertoire peut contenir un lien symbolique, et ainsi  de  suite).
       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 maximale de  récursivité  et  au  nombre  maximal  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 »).

       Tel que mis en œuvre dans Linux, le nombre  maximal  de  liens  symboliques  pouvant  être
       suivis pour la résolution de chemin est 40. Avant Linux 2.6.18, la limite de profondeur de
       récursion était 5. Depuis Linux 2.6.18, cette limite a été relevée à 8. Dans Linux 4.2, le
       code  du  noyau pour la résolution de chemin a été retravaillé pour éliminer l’utilisation
       de la récursion, aussi la seule limite qui demeure est le maximum de  40 résolutions  pour
       le chemin complet.

       La  résolution  de  liens  symboliques  dans  cette  étape  peut être bloquée en utilisant
       openat2(2), avec l’attribut RESOLVE_NO_SYMLINKS établi.

   É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  pour
       les  autres  composants, comme décrit dans l'étape précédente, avec deux différences : (1)
       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 (2) ce n'est peut-être pas  une  erreur  si  le
       composant  n'est  pas  trouvé  — peut-être  vient-il  juste  d’être  créé.  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
       physique.

       Il n’est pas possible de remonter au-dessus de 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.

       Le  parcours de points de montage peut être bloqué en utilisant openat2(2) avec l’attribut
       RESOLVE_NO_XDEV établi (remarquez cependant que cela  restreint  le  parcours  de  montage
       « bind »).

   Barres obliques de fin
       Si  un nom de chemin se termine par un « / », cela force la résolution du composant qui le
       précède comme décrit dans l'étape 2 :  le  composant  avant  l’oblique  finale  doit  soit
       exister  et  être  résolu  comme  répertoire,  soit évoquer un répertoire devant être créé
       immédiatement après la résolution du chemin. Autrement, un « / » final est ignoré.

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

   Limite de longueur
       Il  existe  une  longueur  maximale  pour  les  noms de chemin. 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
       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'ID du 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 « ID  utilisateur  du  système  de  fichiers »
       (« filesystem  user  ID »). Le concept était requis pour l'implémentation d'un serveur NFS
       en espace utilisateur lorsque les processus pouvaient envoyer un signal à un processus qui
       avait  le  même  UID  effectif.  Il est aujourd'hui obsolète. Personne ne devrait utiliser
       setfsuid(2).

       De la même manière, Linux utilise le fsgid (ID de groupe du  système  de  fichiers)  à  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 contourne 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 de permission
       d'exécution de fichier est établi.

       La capacité CAP_DAC_READ_SEARCH accorde 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)

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>, David Prévot <david@tilapin.org>  et  Jean-Paul  Guillonneau
       <guillonneau.jeanpaul@free.fr>

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