path_resolution(7) Miscellaneous Information Manual path_resolution(7)
NOM
path_resolution - Trouver le fichier auquel un chemin fait reference
DESCRIPTION
Certains appels systeme UNIX/Linux ont pour parametre un ou plusieurs
noms de fichier. Un nom de fichier (ou chemin) est resolu de la maniere
suivante.
Etape 1 : demarrer le processus de resolution
Si le chemin debute par le caractere << / >>, le repertoire de
recherche de depart est le repertoire racine du processus appelant. Un
processus herite son repertoire racine de son parent. Habituellement,
c'est le repertoire racine de la hierarchie des fichiers. Un processus
peut avoir un repertoire racine different avec l'utilisation de l'appel
systeme chroot(2) ou peut temporairement utiliser un repertoire racine
different en utilisant openat2(2) avec l'attribut RESOLVE_IN_ROOT
defini.
Un processus peut obtenir un espace de noms montage completement prive
dans le cas ou il -- ou un de ses ancetres -- a ete demarre par une
invocation de l'appel systeme clone(2) dont l'attribut CLONE_NEWNS est
defini. Cela gere la partie << / >> du chemin.
Si le chemin ne debute pas par le caractere << / >>, le repertoire de
recherche de depart du processus de resolution est le repertoire
courant du processus -- ou dans le cas d'appel systeme du style
openat(2), l'argument dfd (ou le repertoire courant de travail si
AT_FDCWD est passe en tant qu'argument dfd). Le repertoire courant de
travail est herite du parent et peut etre modifie avec l'appel systeme
chdir(2).
Les chemins debutant par le caractere << / >> sont appeles chemins
absolus. Les chemins ne debutant pas par le caractere << / >> sont
appeles chemins relatifs.
Etape 2 : parcourir le chemin
Definir le repertoire courant de recherche au repertoire de demarrage
de recherche. Puis pour chaque composant non terminal du chemin, ou un
composant est une sous-chaine delimitee par des caracteres << / >>, ce
composant est recherche dans le repertoire courant de recherche.
Si le processus n'a pas les permissions necessaires pour effectuer la
recherche dans le repertoire de recherche courant, une erreur EACCES
est renvoyee (<< Permission denied >> : << Permission non accordee >>).
Si le composant n'est pas trouve, une erreur ENOENT est renvoyee (<< No
such file or directory >> : << Aucun fichier ou repertoire de ce
type >>).
Si le composant est trouve, mais n'est ni un repertoire ni un lien
symbolique, une erreur ENOTDIR est renvoyee (<< Not a directory >> :
<< N'est pas un repertoire >>).
Si le composant est trouve et est un repertoire, le repertoire de
recherche courant devient ce repertoire et on passe au composant
suivant.
Si le composant est trouve et est un lien symbolique, on resout d'abord
ce lien (avec le repertoire de recherche courant comme repertoire de
recherche de depart). Si une erreur survient, cette erreur est
renvoyee. Si le resultat de la resolution n'est pas un repertoire, une
erreur ENOTDIR est renvoyee. Si la resolution du lien symbolique est
couronnee de succes et renvoie un repertoire, le repertoire de
recherche courant devient ce repertoire et on passe au composant
suivant. Veuillez noter que le processus de resolution peut impliquer
une recursivite si le composant prefixe (<< dirname >>) du chemin
contient un nom de fichier qui est un lien symbolique qui mene a un
repertoire (ou le composant prefixe de ce repertoire peut contenir un
lien symbolique, et ainsi de suite). Afin de proteger le noyau d'un
debordement de pile et egalement d'un deni de service, il y a des
limites a la profondeur maximale de recursivite et au nombre maximal de
liens symboliques suivis. Une erreur ELOOP est renvoyee lors ces maxima
sont atteints (<< Too many levels of symbolic links >> : << Trop de
niveaux de liens symboliques >>).
Tel que mis en oeuvre dans Linux, le nombre maximal de liens
symboliques pouvant etre suivis pour la resolution de chemin est 40.
Avant Linux 2.6.18, la limite de profondeur de recursion etait 5.
Depuis Linux 2.6.18, cette limite a ete relevee a 8. Dans Linux 4.2, le
code du noyau pour la resolution de chemin a ete retravaille pour
eliminer l'utilisation de la recursion, aussi la seule limite qui
demeure est le maximum de 40 resolutions pour le chemin complet.
La resolution de liens symboliques dans cette etape peut etre bloquee
en utilisant openat2(2), avec l'attribut RESOLVE_NO_SYMLINKS etabli.
Etape 3 : trouver l'entree finale
La recherche du dernier composant du nom de chemin s'effectue de la
meme maniere que pour les autres composants, comme decrit dans l'etape
precedente, avec deux differences : (1) le composant final n'a pas
besoin d'etre un repertoire (du moins tant que le processus de
resolution du chemin est concerne -- il peut etre ou ne pas etre un
repertoire, suivant les exigences de l'appel systeme concerne), et (2)
ce n'est peut-etre pas une erreur si le composant n'est pas trouve
-- peut-etre vient-il juste d'etre cree. Les details du traitement du
composant final sont decrits dans les pages de manuel des appels
systeme concernes.
. et ..
Par convention, chaque repertoire possede les entrees . et .. qui se
rapportent, respectivement, au repertoire lui-meme et a son repertoire
parent.
Le processus de resolution de chemin considere que ces entrees ont
leurs sens conventionnels, sans consideration de leur existence ou non
sur le systeme de fichiers physique.
Il n'est pas possible de remonter au-dessus de la racine : /.. est
identique a /.
Points de montage
Apres une commande mount peripherique chemin, le nom de chemin chemin
fait reference a la racine de la hierarchie du systeme de fichiers sur
le peripherique, et plus du tout a ce qu'il referencait precedemment.
On peut sortir d'un systeme de fichiers monte : chemin/.. fait
reference au repertoire parent de chemin, en dehors de la hierarchie du
systeme de fichiers sur peripherique.
Le parcours de points de montage peut etre bloque en utilisant
openat2(2) avec l'attribut RESOLVE_NO_XDEV etabli (remarquez cependant
que cela restreint le parcours de montage << bind >>).
Barres obliques de fin
Si un nom de chemin se termine par un << / >>, cela force la resolution
du composant qui le precede comme decrit dans l'etape 2 : le composant
avant l'oblique finale doit soit exister et etre resolu comme
repertoire, soit evoquer un repertoire devant etre cree immediatement
apres la resolution du chemin. Autrement, un << / >> final est ignore.
Lien symbolique final
Si le dernier composant d'un nom de chemin est un lien symbolique, cela
depend de l'appel systeme si le fichier reference sera le lien
symbolique ou bien le resultat de la resolution de chemin sur son
contenu. Par exemple, l'appel systeme lstat(2) agit sur le lien
symbolique alors que stat(2) agit sur le fichier pointe par le lien
symbolique.
Limite de longueur
Il existe une longueur maximale pour les noms de chemin. Si le chemin
(ou un chemin intermediaire obtenu en resolvant un lien symbolique) est
trop long, une erreur ENAMETOOLONG est renvoyee (<< Filename too
long >> : << Nom de fichier trop long >>).
Nom de chemin vide
Dans l'UNIX d'origine, un nom de chemin vide faisait reference au
repertoire courant. Aujourd'hui, POSIX decrete qu'un nom de fichier
vide ne doit pas etre resolu avec succes. 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
utilise lorsque l'UID effectif du processus appelant est egal a l'ID du
proprietaire du fichier. Le deuxieme de ces groupes est utilise lorsque
le GID du fichier est soit egal au GID effectif du processus appelant,
soit est un des GID supplementaires du processus appelant (comme
configure avec setgroups(2)). Lorsqu'aucun ne correspond, le troisieme
groupe est utilise.
Des trois bits utilises, le premier determine la permission de lecture,
le deuxieme la permission d'ecriture et le dernier la permission
d'execution dans le cas d'un fichier ordinaire ou la permission de
recherche dans le cas d'un repertoire.
Linux utilise le fsuid a la place de l'UID effectif lors de la
verification des permissions. D'ordinaire, le fsuid est egal a l'UID
effectif, mais le fsuid peut etre modifie avec l'appel systeme
setfsuid(2).
Ici, << fsuid >> signifie quelque chose comme << ID utilisateur du
systeme de fichiers >> (<< filesystem user ID >>). Le concept etait
requis pour l'implementation d'un serveur NFS en espace utilisateur
lorsque les processus pouvaient envoyer un signal a un processus qui
avait le meme UID effectif. Il est aujourd'hui obsolete. Personne ne
devrait utiliser setfsuid(2).
De la meme maniere, Linux utilise le fsgid (ID de groupe du systeme de
fichiers) a la place du GID effectif. Consultez setfsgid(2).
Contourner les verifications de permissions : superutilisateur et capacites
Sur un systeme UNIX traditionnel, le superutilisateur (root,
d'identifiant 0) est tout-puissant et contourne toutes les restrictions
de permissions lorsqu'il accede a des fichiers.
Sous Linux, les privileges du superutilisateur sont divises en
capacites (consultez capabilities(7)). Deux de ces capacites sont liees
aux verifications d'acces aux fichiers : CAP_DAC_OVERRIDE et
CAP_DAC_READ_SEARCH. (Un processus a ces capacites si son fsuid est 0.)
La capacite CAP_DAC_OVERRIDE ecrase toutes les verifications de
permission, mais n'assurera la permission d'execution que si au moins
un des trois bits de permission d'execution de fichier est etabli.
La capacite CAP_DAC_READ_SEARCH accorde la permission de lecture et de
recherche sur les repertoires et la permission de lecture sur les
fichiers ordinaires.
VOIR AUSSI
readlink(2), capabilities(7), credentials(7), symlink(7)
TRADUCTION
La traduction francaise de cette page de manuel a ete creee par
Christophe Blaess , Stephan Rafin
, Thierry Vignaud ,
Francois Micaux, Alain Portal , Jean-Philippe
Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas
Huriaux , Nicolas Francois
, Florentin Duneau
, Simon Paillard , Denis Barbier , David Prevot
et Jean-Paul Guillonneau
Cette traduction est une documentation libre ; veuillez vous reporter a
la GNU General Public License version 3
concernant les conditions
de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE.
Si vous decouvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message a .
Pages du manuel de Linux 6.06 31 octobre 2023 path_resolution(7)