path_resolution | Début | Suivant | Sommaire | Préc.page.lue | Accueil |
NOM | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
DESCRIPTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Étape 1 : Démarrer le processus de résolution | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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. (Lui aussi est hérité du père. Il peut être modifié avec l'appel système chdir(2).)
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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 refusée », Ndt : « Permission denied »).
Si le composant n'est pas trouvé, une erreur ENOENT est renvoyée (« Pas de tel fichier ou répertoire », Ndt : « No such file or directory »). Si le composant est trouvé mais que ce n'est ni un répertoire, ni un lien symbolique, une erreur ENOTDIR est renvoyée (« Pas un répertoire », Ndt : « Not a directory »).
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.
Si le composant est trouvé et que c'est un lien symbolique, on résoud 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 ENOTDIR 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 implique une récursivité. 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 maximum de récursivité et aux nombres maximum de liens symboliques suivis. Une erreur ELOOP est renvoyée lors ces maxima sont atteints (« Trop de niveaux de liens symboliques », Ndt : « Too many levels of symbolic links »).
Étape 3 : Trouver l'entrée finale | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
. et .. | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Le processus de résolution de chemin considère que ces entrées ont leurs sens conventionnels, sans considération de leur emplacement actuel sur le système de fichier.
On ne peut plus sortir passée la racine : /.. est identique à /.
Points de montage | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 hierarchie du système de fichiers sur dev.
Barres obliques de fin | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Lien symbolique final | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Limite de longueur | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Nom de chemin vide | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Permissions | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
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 fichier » (Ndt : file system user ID). Le concept était requis pour l'implémentation du serveur NFS 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 (« file system group ID ») à la place du GID effectif. Voir setfsgid(2).
Éviter les vérifications de permissions : superutilisateur et capacités | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Sous Linux, les privilèges du superutilisateur sont divisés en capacités (voir capabilities(7)). Deux capacités ont un rapport avec la vérification des permissions des fichiers : CAP_DAC_OVERRIDE et CAP_DAC_READ_SEARCH. (Un processus a ces capacités si son fsuid vaut 0.)
La capacité CAP_DAC_OVERRIDE écrase toutes les vérifications de permission mais assurera la permission d'exécution si au moins un des trois bits d'exécution du fichier 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 | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
TRADUCTION | Début | Précédent | Suivant | Sommaire | Préc.page.lue | Accueil |
Ce document est une traduction réalisée par Alain Portal <aportal AT univ-montp2 DOT fr> le 9 mai 2006 et révisée le 8 janvier 2008.
L'équipe de traduction a fait le maximum pour réaliser une adaptation française de qualité. La version anglaise la plus à jour de ce document est toujours consultable via la commande : « LANG=C man 2 path_resolution ». N'hésitez pas à signaler à l'auteur ou au traducteur, selon le cas, toute erreur dans cette page de manuel.
Sommaire | Début | Suivant | Sommaire | Préc.page.lue | Accueil |