NOM
Résolution de chemin sous Unix/Linux - Trouver le fichier référencé par
son nom
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 non accordé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 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 priphrique chemin, le nom de chemin chemin
fait référence à la racine de la hiérarchie du système de fichiers sur
le priphrique, 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 priphrique.
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 (« 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 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 » (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 à la place du GID effectif.
Voir 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 (voir 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
capabilities(7), credentials(7), symlink(7)
COLOPHON
Cette page fait partie de la publication 3.23 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
Cette page de manuel a été traduite et mise à jour par Alain Portal
<aportal AT univ-montp2 DOT fr> entre 2004 et 2006, et mise à
disposition sur http://manpagesfr.free.fr/.
Les mises à jour et corrections de la version présente dans Debian sont
directement gérées par Julien Cristau <jcristau@debian.org> et l’équipe
francophone de traduction de Debian.
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> ».