.\" -*- coding: UTF-8 -*-
.\" Copyright (C) 2003 Andries Brouwer (aeb@cwi.nl)
.\"
.\" SPDX-License-Identifier: Linux-man-pages-copyleft
.\"
.\"*******************************************************************
.\"
.\" This file was generated with po4a. Translate the source file.
.\"
.\"*******************************************************************
.TH path_resolution 7 "31 octobre 2023" "Pages du manuel de Linux 6.06"
.SH NOM
path_resolution – Trouver le fichier auquel un chemin fait référence
.SH DESCRIPTION
Certains appels système UNIX/Linux ont pour paramètre un ou plusieurs noms
de fichier. Un nom de fichier (ou chemin) est résolu de la manière suivante.
.SS "Étape 1\ : démarrer le processus de résolution"
Si le chemin débute par 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 parent. 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 \fBchroot\fP(2) ou peut
temporairement utiliser un répertoire racine différent en utilisant
\fBopenat2\fP(2) avec l’attribut \fBRESOLVE_IN_ROOT\fP défini.
.P
Un processus peut obtenir un espace de noms montage complètement privé dans
le cas ou il \[em]\ ou un de ses ancêtres\ \[em] a été démarré par une
invocation de l’appel système \fBclone\fP(2) dont l’attribut \fBCLONE_NEWNS\fP est
défini. Cela gère la partie « / » du chemin.
.P
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 \[em]\ ou dans le cas d’appel système du style \fBopenat\fP(2),
l’argument \fIdfd\fP (ou le répertoire courant de travail si \fBAT_FDCWD\fP est
passé en tant qu’argument \fIdfd\fP). Le répertoire courant de travail est
hérité du parent et peut être modifié avec l'appel système \fBchdir\fP(2).
.P
Les chemins débutant par le caractère «\ /\ » sont appelés chemins
absolus. Les chemins ne débutant pas par le caractère «\ /\ » sont appelés
chemins relatifs.
.SS "Étape 2\ : parcourir le chemin"
Définir le répertoire courant de recherche au répertoire de démarrage de
recherche. Puis pour chaque composant non terminal du chemin, où un
composant est une sous\-chaine délimitée par des caractères « / », ce
composant est recherché dans le répertoire courant de recherche.
.P
Si le processus n'a pas les permissions nécessaires pour effectuer la
recherche dans le répertoire de recherche courant, une erreur \fBEACCES\fP est
renvoyée (« Permission denied » : « Permission non accordée »).
.P
Si le composant n'est pas trouvé, une erreur \fBENOENT\fP est renvoyée (« No
such file or directory » : « Aucun fichier ou répertoire de ce type »).
.P
Si le composant est trouvé, mais n'est ni un répertoire ni un lien
symbolique, une erreur \fBENOTDIR\fP est renvoyée (« Not a directory » :
« N'est pas un répertoire »).
.P
Si le composant est trouvé et est un répertoire, le répertoire de recherche
courant devient ce répertoire et on passe au composant suivant.
.P
Si le composant est trouvé et 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 \fBENOTDIR\fP 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 peut impliquer une récursivité si le composant préfixe
(« dirname ») du chemin contient un nom de fichier qui est un lien
symbolique qui mène à un répertoire (où le composant préfixe de ce
répertoire peut contenir un lien symbolique, et ainsi de suite). 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 maximale de récursivité et au
nombre maximal de liens symboliques suivis. Une erreur \fBELOOP\fP est renvoyée
lors ces maxima sont atteints (« Too many levels of symbolic links » :
« Trop de niveaux de liens symboliques »).
.P
.\"
.\" presently: max recursion depth during symlink resolution: 5
.\" max total number of symbolic links followed: 40
.\" _POSIX_SYMLOOP_MAX is 8
.\" MAXSYMLINKS is 40
.\" MAX_NESTED_LINKS
.\" commit 894bc8c4662ba9daceafe943a5ba0dd407da5cd3
Tel que mis en œuvre dans Linux, le nombre maximal de liens symboliques
pouvant être suivis pour la résolution de chemin est 40. Avant Linux 2.6.18,
la limite de profondeur de récursion était 5. Depuis Linux 2.6.18, cette
limite a été relevée à 8. Dans Linux 4.2, le code du noyau pour la
résolution de chemin a été retravaillé pour éliminer l’utilisation de la
récursion, aussi la seule limite qui demeure est le maximum de
40 résolutions pour le chemin complet.
.P
La résolution de liens symboliques dans cette étape peut être bloquée en
utilisant \fBopenat2\fP(2), avec l’attribut \fBRESOLVE_NO_SYMLINKS\fP établi.
.SS "É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 pour les autres composants, comme décrit dans l'étape
précédente, avec deux différences\ : (1) 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é \[em]\ il peut être ou ne pas être un répertoire, suivant les
exigences de l'appel système concerné), et (2) ce n'est peut\-être pas une
erreur si le composant n'est pas trouvé \[em]\ peut\-être vient\-il juste
d’être créé. Les détails du traitement du composant final sont décrits dans
les pages de manuel des appels système concernés.
.SS ". et .."
Par convention, chaque répertoire possède les entrées \fI.\fP et \fI..\fP qui se
rapportent, respectivement, au répertoire lui\-même et à son répertoire
parent.
.P
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 physique.
.P
Il n’est pas possible de remonter au\-dessus de la racine\ : \fI/..\fP est
identique à \fI/\fP.
.SS "Points de montage"
Après une commande \fImount périphérique chemin\fP, le nom de chemin \fIchemin\fP
fait référence à la racine de la hiérarchie du système de fichiers sur le
\fIpériphérique\fP, et plus du tout à ce qu'il référençait précédemment.
.P
On peut sortir d'un système de fichiers monté\ : \fIchemin/..\fP fait référence
au répertoire parent de \fIchemin\fP, en dehors de la hiérarchie du système de
fichiers sur \fIpériphérique\fP.
.P
Le parcours de points de montage peut être bloqué en utilisant \fBopenat2\fP(2)
avec l’attribut \fBRESOLVE_NO_XDEV\fP établi (remarquez cependant que cela
restreint le parcours de montage « bind »).
.SS "Barres obliques de fin"
Si un nom de chemin se termine par un «\ /\ », cela force la résolution du
composant qui le précède comme décrit dans l'étape 2 : le composant avant
l’oblique finale doit soit exister et être résolu comme répertoire, soit
évoquer un répertoire devant être créé immédiatement après la résolution du
chemin. Autrement, un «\ /\ » final est ignoré.
.SS "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 \fBlstat\fP(2) agit sur le lien symbolique alors que \fBstat\fP(2)
agit sur le fichier pointé par le lien symbolique.
.SS "Limite de longueur"
Il existe une longueur maximale pour les noms de chemin. Si le chemin (ou un
chemin intermédiaire obtenu en résolvant un lien symbolique) est trop long,
une erreur \fBENAMETOOLONG\fP est renvoyée (« Filename too long » : « Nom de
fichier trop long »).
.SS "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 \fBENOENT\fP dans ce cas.
.SS Permissions
Les bits de permissions d'un fichier consistent en trois groupes de trois
bits, cf.\& \fBchmod\fP(1) et \fBstat\fP(2). Le premier de ces groupes est utilisé
lorsque l'UID effectif du processus appelant est égal à l'ID du 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
\fBsetgroups\fP(2)). Lorsqu'aucun ne correspond, le troisième groupe est
utilisé.
.P
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.
.P
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 \fBsetfsuid\fP(2).
.P
Ici, «\ fsuid\ » signifie quelque chose comme «\ ID utilisateur du système
de fichiers\ » (« filesystem user ID »). Le concept était requis pour
l'implémentation d'un serveur NFS en espace utilisateur lorsque les
processus pouvaient envoyer un signal à un processus qui avait le même UID
effectif. Il est aujourd'hui obsolète. Personne ne devrait utiliser
\fBsetfsuid\fP(2).
.P
.\" FIXME . say something about filesystem mounted read-only ?
De la même manière, Linux utilise le fsgid (ID de groupe du système de
fichiers) à la place du GID effectif. Consultez \fBsetfsgid\fP(2).
.SS "Contourner les vérifications de permissions\ : superutilisateur et capacités"
.\" (but for exec at least one x bit must be set) -- AEB
.\" but there is variation across systems on this point: for
.\" example, HP-UX and Tru64 are as described by AEB. However,
.\" on some implementations (e.g., Solaris, FreeBSD),
.\" access(X_OK) by superuser will report success, regardless
.\" of the file's execute permission bits. -- MTK (Oct 05)
Sur un système UNIX traditionnel, le superutilisateur (\fIroot\fP,
d'identifiant 0) est tout\-puissant et contourne toutes les restrictions de
permissions lorsqu'il accède à des fichiers.
.P
Sous Linux, les privilèges du superutilisateur sont divisés en capacités
(consultez \fBcapabilities\fP(7)). Deux de ces capacités sont liées aux
vérifications d'accès aux fichiers\ : \fBCAP_DAC_OVERRIDE\fP et
\fBCAP_DAC_READ_SEARCH\fP. (Un processus a ces capacités si son fsuid est 0.)
.P
La capacité \fBCAP_DAC_OVERRIDE\fP écrase toutes les vérifications de
permission, mais n'assurera la permission d'exécution que si au moins un des
trois bits de permission d'exécution de fichier est établi.
.P
.\" FIXME . say something about immutable files
.\" FIXME . say something about ACLs
La capacité \fBCAP_DAC_READ_SEARCH\fP accorde la permission de lecture et de
recherche sur les répertoires et la permission de lecture sur les fichiers
ordinaires.
.SH "VOIR AUSSI"
\fBreadlink\fP(2), \fBcapabilities\fP(7), \fBcredentials\fP(7), \fBsymlink\fP(7)
.PP
.SH TRADUCTION
La traduction française de cette page de manuel a été créée par
Christophe Blaess ,
Stéphan Rafin ,
Thierry Vignaud ,
François Micaux,
Alain Portal ,
Jean-Philippe Guérard ,
Jean-Luc Coulon (f5ibh) ,
Julien Cristau ,
Thomas Huriaux ,
Nicolas François ,
Florentin Duneau ,
Simon Paillard ,
Denis Barbier ,
David Prévot
et
Jean-Paul Guillonneau
.
.PP
Cette traduction est une documentation libre ; veuillez vous reporter à la
.UR https://www.gnu.org/licenses/gpl-3.0.html
GNU General Public License version 3
.UE
concernant les conditions de copie et
de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.
.PP
Si vous découvrez un bogue dans la traduction de cette page de manuel,
veuillez envoyer un message à
.MT debian-l10n-french@lists.debian.org
.ME .