Provided by:
manpages-fr_3.32d0.2p4-1_all 
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 fichiers. Un nom de fichier (ou chemin) est resolu de la
maniere suivante.
'Etape 1 : D'emarrer le processus de r'esolution
Si le chemin debute avec le caractere << / >>, le repertoire de
recherche de depart est le repertoire racine du processus appelant. (Un
processus herite son repertoire racine de son pere. 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). Un processus peut recuperer un espace noms de
montage prive entier dans le cas ou lui -- ou un de ses parents -- a
ete demarre par une invocation de l'appel systeme clone(2) avec
l'attribut CLONE_NEWNS positionne.) 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. (Lui aussi est herite du pere. Il peut etre
modifie avec l'appel systeme chdir(2).)
Les chemins debutant avec le caractere << / >> sont appeles chemins
absolus. Les chemins ne debutant pas avec le caractere << / >> sont
appeles chemins relatifs.
'Etape 2 : Se promener le long du chemin
Le repertoire de recherche courant est le repertoire de recherche de
depart. On appellera composant d'un chemin une sous-chaine delimitee
par des caracteres << / >>. Chaque composant du chemin qui n'est pas le
composant final est recherche dans le repertoire de recherche courant.
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 que ce 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 que c'est un repertoire, le repertoire de
recherche courant devient ce repertoire et on passe au composant
suivant.
Si le composant est trouve et que c'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
implique une recursivite. 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 maximum de recursivite et aux nombres maximum 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 >>).
'Etape 3 : Trouver l'entr'ee finale
La recherche du dernier composant du nom de chemin s'effectue de la
meme maniere que les autres composants, comme decrit dans l'etape
precedente, avec deux differences : (i) 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 (ii)
ce n'est peut-etre pas une erreur si le composant n'est pas trouve --
peut-etre vient on juste de le creer. 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.
On ne peut plus sortir passee la racine : /.. est identique a /.
Points de montage
Apres une commande mount p'eriph'erique chemin, le nom de chemin chemin
fait reference a la racine de la hierarchie du systeme de fichiers sur
le p'eriph'erique, et plus du tout 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 p'eriph'erique.
Barres obliques de fin
Si un nom de chemin finit avec un << / >>, cela force la resolution du
composant qui le precede comme decrit dans l'etape 2 -- le composant
doit exister et etre resolu comme repertoire. Autrement, un << / >>
final est ignore. (Ou bien, de maniere equivalente, un nom de chemin
avec un << / >> final est equivalent au nom de chemin obtenu en
ajoutant << . >> a la fin.)
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.
Limite de longueur
Il y a une longueur maximum pour les noms de chemins. Si le chemin (ou
un chemin intermediaire obtenu en resolvant un lien symbolique) est
trop long, une erreur ENAMETOOLONG est renvoyee (<< File name 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'UID
reel (le 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 << UID systeme de
fichiers >> (<< file system user ID >>). Le concept etait requis pour
l'implementation d'un serveur NFS en espace utilisateur au moment ou
les processus pouvaient envoyer un signal a un processus qui avait le
meme UID effectif. Il est aujourd'hui obsolete. Personne ne devrait
plus utiliser setfsuid(2).)
De la meme maniere, Linux utilise le fsgid a la place du GID effectif.
Consultez setfsgid(2).
Contourner les v'erifications de permissions : superutilisateur et capacit'es
Sur un systeme UNIX traditionnel, le superutilisateur (root,
d'identifiant 0) est tout-puissant, et shunte 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 d'execution est a 1.
La capacite CAP_DAC_READ_SEARCH assurera 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)
COLOPHON
Cette page fait partie de la publication 3.32 du projet man-pages
Linux. Une description du projet et des instructions pour signaler des
anomalies peuvent etre trouvees a l'adresse
<URL:http://www.kernel.org/doc/man-pages/>.
TRADUCTION
Depuis 2010, cette traduction est maintenue a l'aide de l'outil po4a
<URL:http://po4a.alioth.debian.org/> par l'equipe de traduction
francophone au sein du projet perkamon
<URL:http://perkamon.alioth.debian.org/>.
Alain Portal <URL:http://manpagesfr.free.fr/> (2004-2006). Julien
Cristau et l'equipe francophone de traduction de Debian (2006-2009).
Veuillez signaler toute erreur de traduction en ecrivant a
<debian-l10n-french@lists.debian.org> ou par un rapport de bogue sur le
paquet manpages-fr.
Vous pouvez toujours avoir acces a la version anglaise de ce document
en utilisant la commande << man -L C <section> <page_de_man> >>.
Linux 5 decembre 2009 PATH_RESOLUTION(7)