Provided by: manpages-fr_3.65d1p1-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 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 (« 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'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 » (« filesystem
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.65 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
Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a
<http://po4a.alioth.debian.org/> par l'équipe de traduction francophone au sein du projet
perkamon <http://perkamon.alioth.debian.org/>.
Alain Portal <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> ».