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)