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