Provided by: manpages-fr_4.26.0-1_all 
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 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.
Pages du manuel de Linux 6.9.1 2 mai 2024 path_resolution(7)