.\" -*- coding: UTF-8 -*- .\" Copyright (C) 2003 Andries Brouwer (aeb@cwi.nl) .\" .\" %%%LICENSE_START(VERBATIM) .\" Permission is granted to make and distribute verbatim copies of this .\" manual provided the copyright notice and this permission notice are .\" preserved on all copies. .\" .\" Permission is granted to copy and distribute modified versions of this .\" manual under the conditions for verbatim copying, provided that the .\" entire resulting derived work is distributed under the terms of a .\" permission notice identical to this one. .\" .\" Since the Linux kernel and libraries are constantly changing, this .\" manual page may be incorrect or out-of-date. The author(s) assume no .\" responsibility for errors or omissions, or for damages resulting from .\" the use of the information contained herein. The author(s) may not .\" have taken the same level of care in the production of this manual, .\" which is licensed free of charge, as they might when working .\" professionally. .\" .\" Formatted or processed versions of this manual, if unaccompanied by .\" the source, must acknowledge the copyright and authors of this work. .\" %%%LICENSE_END .\" .\"******************************************************************* .\" .\" This file was generated with po4a. Translate the source file. .\" .\"******************************************************************* .TH PATH_RESOLUTION 7 "11 avril 2020" Linux "Manuel du programmeur Linux" .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 fichiers. Un nom de fichier (ou chemin) est résolu de la manière suivante. .SS "Étape 1\ : Démarrer le processus de résolution" If the pathname starts with the \(aq/\(aq character, the starting lookup directory is the root directory of the calling process. A process inherits its root directory from its parent. Usually this will be the root directory of the file hierarchy. A process may get a different root directory by use of the \fBchroot\fP(2) system call, or may temporarily use a different root directory by using \fBopenat2\fP(2) with the \fBRESOLVE_IN_ROOT\fP flag set. .PP A process may get an entirely private mount namespace in case it\(emor one of its ancestors\(emwas started by an invocation of the \fBclone\fP(2) system call that had the \fBCLONE_NEWNS\fP flag set. This handles the \(aq/\(aq part of the pathname. .PP If the pathname does not start with the \(aq/\(aq character, the starting lookup directory of the resolution process is the current working directory of the process \(em or in the case of \fBopenat\fP(2)\-style system calls, the \fIdfd\fP argument (or the current working directory if \fBAT_FDCWD\fP is passed as the \fIdfd\fP argument). The current working directory is inherited from the parent, and can be changed by use of the \fBchdir\fP(2) system call.) .PP 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. .SS "É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. .PP 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\ »). .PP 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\ »). .PP Si le composant est trouvé mais que ce 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\ »). .PP 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. .PP If the component is found and is a symbolic link (symlink), we first resolve this symbolic link (with the current lookup directory as starting lookup directory). Upon error, that error is returned. If the result is not a directory, an \fBENOTDIR\fP error is returned. If the resolution of the symbolic link is successful and returns a directory, we set the current lookup directory to that directory, and go to the next component. Note that the resolution process here can involve recursion if the prefix ('dirname') component of a pathname contains a filename that is a symbolic link that resolves to a directory (where the prefix component of that directory may contain a symbolic link, and so on). In order to protect the kernel against stack overflow, and also to protect against denial of service, there are limits on the maximum recursion depth, and on the maximum number of symbolic links followed. An \fBELOOP\fP error is returned when the maximum is exceeded ("Too many levels of symbolic links"). .PP .\" .\" 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 As currently implemented on Linux, the maximum number of symbolic links that will be followed while resolving a pathname is 40. In kernels before 2.6.18, the limit on the recursion depth was 5. Starting with Linux 2.6.18, this limit was raised to 8. In Linux 4.2, the kernel's pathname\-resolution code was reworked to eliminate the use of recursion, so that the only limit that remains is the maximum of 40 resolutions for the entire pathname. .PP The resolution of symbolic links during this stage can be blocked by using \fBopenat2\fP(2), with the \fBRESOLVE_NO_SYMLINKS\fP flag set. .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 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é \(em 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é \(em 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. .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. .PP 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. .PP One cannot walk up past the root: "/.." is the same as "/". .SS "Points de montage" Après une commande \fBmount\fP \fIpé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. .PP 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. .PP Traversal of mount points can be blocked by using \fBopenat2\fP(2), with the \fBRESOLVE_NO_XDEV\fP flag set (though note that this also restricts bind mount traversal). .SS "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 \(em 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.) .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. .SS "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 \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 The permission bits of a file consist of three groups of three bits; see \fBchmod\fP(1) and \fBstat\fP(2). The first group of three is used when the effective user ID of the calling process equals the owner ID of the file. The second group of three is used when the group ID of the file either equals the effective group ID of the calling process, or is one of the supplementary group IDs of the calling process (as set by \fBsetgroups\fP(2)). When neither holds, the third group is used. .PP 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. .PP 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). .PP (Ici, «\ fsuid\ » signifie quelque chose comme «\ UID système de fichiers\ » («\ filesystem 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 \fBsetfsuid\fP(2).) .PP .\" FIXME . say something about filesystem mounted read-only ? De la même manière, Linux utilise le fsgid à 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 shunte toutes les restrictions de permissions lorsqu'il accède à des fichiers. .PP 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.) .PP 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 d'exécution est à 1. .PP .\" FIXME . say something about immutable files .\" FIXME . say something about ACLs La capacité \fBCAP_DAC_READ_SEARCH\fP assurera 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) .SH COLOPHON Cette page fait partie de la publication\ 5.10 du projet \fIman\-pages\fP Linux. Une description du projet et des instructions pour signaler des anomalies et la dernière version de cette page peuvent être trouvées à l'adresse \%https://www.kernel.org/doc/man\-pages/. .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 et David Prévot . .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 .