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 » (« 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. 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.44 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> ».