PATH_RESOLUTION
Section : Manuel du programmeur Linux (
7)
Mise à jour de la version anglaise : 21 juin 2004
Index
Menu principal
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 nom 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 refusé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 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 emplacement actuel sur le
système de fichier.
On ne peut plus sortir passée la racine :
/..
est identique à
/.
Points de montage
Après une commande
mount(8)
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
dev.
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 à un 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
courant 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 (« file system group ID »)
à la place du GID effectif.
Voir
setfsgid(2).
Éviter les vérifications de permissions : superutilisateur et capacités
Sur un système traditionnel Unix, le superutilisateur
(
root,
dont l'UID est 0) est tout puissant et évite toutes les restrictions de
permissions lorsqu'il accède aux fichiers.
Sous Linux, les privilèges du superutilisateur sont divisés en capacités
(voir
capabilities(7)).
Deux capacités ont un rapport avec la vérification des permissions
des fichiers :
CAP_DAC_OVERRIDE
et
CAP_DAC_READ_SEARCH.
(Un processus a ces capacités si son fsuid vaut 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 du fichier 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)
TRADUCTION
Ce document est une traduction réalisée par Alain Portal
<aportal AT univ-montp2 DOT fr> le 9 mai 2006
et révisée le 17 juillet 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation
française de qualité. La version anglaise la plus à jour de ce document est
toujours consultable via la commande : « LANG=C man 2 path_resolution ».
N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute
erreur dans cette page de manuel.
Index
- NOM
-
- DESCRIPTION
-
- Étape 1 : Démarrer le processus de résolution
-
- Étape 2 : Se promener le long du chemin
-
- Étape 3 : Trouver l'entrée finale
-
- . et ..
-
- Points de montage
-
- Barres obliques de fin
-
- Lien symbolique final
-
- Limite de longueur
-
- Nom de chemin vide
-
- Permissions
-
- Éviter les vérifications de permissions : superutilisateur et capacités
-
- VOIR AUSSI
-
- TRADUCTION
-
Dernière mise à jour : 17 juillet 2008