path_resolution

PATH_RESOLUTION(7)         Manuel du programmeur Linux        PATH_RESOLUTION(7)



NOM
       path_resolution - Trouver le fichier auquel un chemin fait référence

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.

   Étape 1 : Démarrer le processus de résolution
       If the pathname starts with the '/' 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 chroot(2)  system call, or may temporarily use a
       different root directory by using openat2(2)  with the RESOLVE_IN_ROOT
       flag set.

       A process may get an entirely private mount namespace in case it—or one
       of its ancestors—was started by an invocation of the clone(2)  system
       call that had the CLONE_NEWNS flag set.  This handles the '/' part of the
       pathname.

       If the pathname does not start with the '/' character, the starting
       lookup directory of the resolution process is the current working
       directory of the process — or in the case of openat(2)-style system
       calls, the dfd argument (or the current working directory if AT_FDCWD is
       passed as the dfd argument).  The current working directory is inherited
       from the parent, and can be changed by use of the chdir(2)  system call.)

       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.

   É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.

       Si le processus n'a pas les permissions nécessaires pour effectuer la
       recherche dans le répertoire de recherche courant, une erreur EACCES est
       renvoyée (« Permission denied » : « Permission non accordée »).

       Si le composant n'est pas trouvé, une erreur ENOENT est renvoyée (« No
       such file or directory » : « Aucun fichier ou répertoire de ce type »).

       Si le composant est trouvé mais que ce n'est ni un répertoire, ni un lien
       symbolique, une erreur ENOTDIR est renvoyée (« Not a directory » :
       « N'est pas un répertoire »).

       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.

       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 ENOTDIR 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 ELOOP error is
       returned when the maximum is exceeded ("Too many levels of symbolic
       links").

       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.

       The resolution of symbolic links during this stage can be blocked by
       using openat2(2), with the RESOLVE_NO_SYMLINKS flag set.

   É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é — 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é — 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.

   . et ..
       Par convention, chaque répertoire possède les entrées . et .., qui se
       rapportent, respectivement, au répertoire lui-même et à son répertoire
       parent.

       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.

       One cannot walk up past the root: "/.." is the same as "/".

   Points de montage
       Après une commande mount périphérique chemin, le nom de chemin chemin
       fait référence à la racine de la hiérarchie du système de fichiers sur le
       périphérique, et plus du tout ce qu'il référençait précédemment.

       On peut sortir d'un système de fichiers monté : chemin/.. fait référence
       au répertoire parent de chemin, en dehors de la hiérarchie du système de
       fichiers sur périphérique.

       Traversal of mount points can be blocked by using openat2(2), with the
       RESOLVE_NO_XDEV flag set (though note that this also restricts bind mount
       traversal).

   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 — 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.)

   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 lstat(2) agit sur le lien symbolique alors que
       stat(2) agit sur le fichier pointé par le lien.

   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 ENAMETOOLONG est renvoyée (« Filename too long » : « Nom
       de fichier trop long »).

   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 ENOENT dans ce cas.

   Permissions
       The permission bits of a file consist of three groups of three bits; see
       chmod(1)  and stat(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 setgroups(2)).
       When neither holds, the third group is used.

       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.

       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
       setfsuid(2).

       (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
       setfsuid(2).)

       De la même manière, Linux utilise le fsgid à la place du GID effectif.
       Consultez setfsgid(2).

   Contourner les vérifications de permissions : superutilisateur et capacités
       Sur un système UNIX traditionnel, le superutilisateur (root,
       d'identifiant 0) est tout-puissant, et shunte toutes les restrictions de
       permissions lorsqu'il accède à des fichiers.

       Sous Linux, les privilèges du superutilisateur sont divisés en capacités
       (consultez capabilities(7)). Deux de ces capacités sont liées aux
       vérifications d'accès aux fichiers : CAP_DAC_OVERRIDE et
       CAP_DAC_READ_SEARCH. (Un processus a ces capacités si son fsuid est 0.)

       La capacité CAP_DAC_OVERRIDE é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.

       La capacité CAP_DAC_READ_SEARCH assurera la permission de lecture et de
       recherche sur les répertoires, 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 5.08 du projet man-pages 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/.


TRADUCTION
       La traduction française de cette page de manuel a été créée par
       Christophe Blaess <https://www.blaess.fr/christophe/>, Stéphan Rafin
       <stephan.rafin@laposte.net>, Thierry Vignaud <tvignaud@mandriva.com>,
       François Micaux, Alain Portal <aportal@univ-montp2.fr>, Jean-Philippe
       Guérard <fevrier@tigreraye.org>, Jean-Luc Coulon (f5ibh) <jean-
       luc.coulon@wanadoo.fr>, Julien Cristau <jcristau@debian.org>, Thomas
       Huriaux <thomas.huriaux@gmail.com>, Nicolas François
       <nicolas.francois@centraliens.net>, Florentin Duneau <fduneau@gmail.com>,
       Simon Paillard <simon.paillard@resel.enst-bretagne.fr>, Denis Barbier
       <barbier@debian.org> et David Prévot <david@tilapin.org>

       Cette traduction est une documentation libre ; veuillez vous reporter à
       la GNU General Public License version 3 concernant les conditions de
       copie et de distribution. Il n'y a aucune RESPONSABILITÉ LÉGALE.

       Si vous découvrez un bogue dans la traduction de cette page de manuel,
       veuillez envoyer un message à <debian-l10n-french@lists.debian.org>.



Linux                             11 avril 2020               PATH_RESOLUTION(7)