access(2) System Calls Manual access(2) NOM access, faccessat, faccessat2 - Verifier les permissions utilisateur d'un fichier BIBLIOTHEQUE Bibliotheque C standard (libc, -lc) SYNOPSIS #include int access(const char *chemin, int mode); #include /* Definition des constantes AT_* */ #include int faccessat(int dirfd, const char *chemin, int mode, int argument); /* Mais voir les differences entre la bibliotheque C et le noyau ci-dessous. */ #include /* Definition des constantes AT_* */ #include /* Definition des constantes SYS_* */ #include int syscall(SYS_faccessat2, int dirfd, const char *chemin, int mode, int arguments); Exigences de macros de test de fonctionnalites pour la glibc (consulter feature_test_macros(7)) : faccessat() : Depuis la glibc 2.10 : _POSIX_C_SOURCE >= 200809L avant la glibc 2.10 : _ATFILE_SOURCE DESCRIPTION access() verifie si le processus appelant peut acceder au fichier chemin. Si chemin est un lien symbolique, il est dereference. Le mode indique les verifications d'acces a effectuer. Il prend la valeur F_OK ou un masque contenant un OU binaire d'une ou plus des valeurs R_OK, W_OK et X_OK. F_OK teste l'existence du fichier. R_OK, W_OK et X_OK testent si le fichier existe et autorisent respectivement la lecture, l'ecriture et l'execution. Le test est effectue avec les UID et GID reels du processus appelant, plutot qu'avec les ID effectifs qui sont utilises lorsque l'on tente une operation (comme open(2)) sur le fichier. De la meme maniere, pour le superutilisateur, le test utilise un ensemble de capacites permises plutot que l'ensemble des capacites effectives, et pour les utilisateurs non privilegies, le test utilise un ensemble vierge de capacites. Cela permet aux programmes Setuid et dotes de capacites de determiner les autorisations de l'utilisateur ayant invoque le programme. En d'autres termes, access() ne repond pas a la question << puis-je lire/ecrire/executer ce fichier ? >>. Il repond a une question legerement differente : << en supposant que je suis un binaire Setuid, l'utilisateur qui m'a appele peut-il lire/ecrire/executer ce fichier ? >>, ce qui donne aux programmes Setuid la possibilite d'empecher des utilisateurs malveillants de lire des fichiers qu'un utilisateur ne devrait pas lire. Si le processus appelant est privilegie (c'est-a-dire son UID reel est zero), alors une verification X_OK reussit pour un fichier regulier si l'execution est permise pour l'utilisateur proprietaire, le groupe ou pour les autres. faccessat() faccessat() opere exactement de la meme maniere que access(), excepte les differences decrites ici. Si le nom de chemin fourni dans chemin est relatif, il est interprete relativement au repertoire reference par le descripteur de fichier dirfd (plutot que relativement au repertoire de travail courant du processus appelant, comme cela est fait par access() pour un chemin relatif). Si chemin est relatif et que dirfd est la valeur speciale AT_FDCWD, chemin est interprete relativement au repertoire de travail courant du processus appelant (comme avec access()). Si pathname est absolu, alors dirfd est ignore. argument est construit en realisant un OU logique entre zero ou plusieurs des valeurs suivantes : AT_EACCESS Realiser les verifications d'acces en utilisant les UID et GID effectifs. Par defaut, faccessat() utilise les ID reels (comme access()). AT_EMPTY_PATH (depuis Linux 5.8) Si chemin est une chaine vide, operer sur le fichier reference par dirfd (qui peut avoir ete obtenu avec l'attribut O_PATH de open(2)). Dans ce cas, dirfd peut faire reference a n'importe quel type de fichier, pas seulement a un repertoire. Si dirfd est AT_FDCWD, l'appel opere sur le repertoire de travail en cours. Cet attribut est specifique a Linux ; definir _GNU_SOURCE pour obtenir sa definition. AT_SYMLINK_NOFOLLOW Si chemin est un lien symbolique, ne pas le dereferencer, mais renvoyer des informations sur le lien lui-meme. Consultez openat(2) pour une explication sur la necessite de faccessat(). faccessat2() La description de faccessat() donnee ci-dessus correspond a POSIX.1 et a l'implementation fournie dans la glibc. Cependant, l'implementation de la glibc etait une emulation imparfaite (voir BOGUES) qui masquait le fait que l'appel systeme faccessat() brut de Linux n'a pas de parametre argument. Pour avoir une implementation correcte, Linux 5.8 a ajoute l'appel systeme faccessat2() qui gere le parametre argument et permet une bonne implementation de la fonction enveloppe faccessat(). VALEUR RENVOYEE En cas de succes (toutes les permissions demandees sont accordees, ou mode vaut F_OK et le fichier existe), 0 est renvoye. En cas d'erreur (au moins une permission de mode est refusee, ou mode vaut F_OK et le fichier n'existe pas, ou d'autres erreurs se sont produites), -1 est renvoye et errno est positionne pour indiquer l'erreur. ERREURS EACCES L'acces est refuse au fichier lui-meme, ou il n'est pas permis de parcourir l'un des repertoires du prefixe de chemin (consultez aussi path_resolution(7)). EBADF (faccessat()) pathname est relatif mais dirfd ne vaut ni AT_FDCWD (faccessat()), ni un descripteur de fichier valable. EFAULT nom_chemin pointe en dehors de l'espace d'adressage accessible. EINVAL mode etait mal indique. EINVAL (faccessat()) Attribut non valable indique dans flags. EIO Une erreur d'entree-sortie s'est produite. ELOOP Trop de liens symboliques ont ete rencontres en parcourant nom_chemin. ENAMETOOLONG nom_chemin est trop long. ENOENT Un composant du chemin d'acces chemin n'existe pas ou est un lien symbolique pointant nulle part. ENOMEM La memoire disponible du noyau n'etait pas suffisante. ENOTDIR Un element, utilise comme repertoire, du chemin d'acces nom_chemin n'est pas en fait un repertoire. ENOTDIR (faccessat()) pathname est relatif et dirfd est un descripteur de fichier faisant reference a un fichier qui n'est pas un dossier. EPERM Une ecriture est demandee sur un fichier ou un attribut immuable est positionne. Voir aussi ioctl_iflags(2). EROFS Une ecriture est demandee sur un systeme de fichiers en lecture seule. ETXTBSY Une ecriture a ete demandee dans un fichier executable qui est en cours d'utilisation. VERSIONS Si le processus appelant a les privileges suffisants (c'est-a-dire est superutilisateur), POSIX.1-2001 permet a une implementation d'indiquer un succes pour X_OK meme si le fichier n'a aucun bit d'execution positionne. Linux ne le permet pas. Differences entre bibliotheque C et noyau L'appel systeme brut faccessat() n'accepte que les trois premiers arguments. Les attributs AT_EACCESS et AT_SYMLINK_NOFOLLOW sont en fait implementes dans la fonction enveloppe de la glibc pour faccessat(). Si un de ces attributs est indique, la fonction enveloppe utilise fstatat(2) pour determiner les droits d'acces, mais voir BOGUES. Notes de la glibc Sur les anciens noyaux ou faccessat() n'est pas disponible (et quand les attributs AT_EACCESS et AT_SYMLINK_NOFOLLOW ne sont pas specifies), la fonction enveloppe de la glibc se rabat sur access(). Quand chemin est un chemin relatif, la glibc construit un chemin a partir du lien symbolique dans /proc/self/fd qui correspond au parametre dirfd. STANDARDS access() faccessat() POSIX.1-2008. faccessat2() Linux. HISTORIQUE access() SVr4, 4.3BSD, POSIX.1-2001. faccessat() Linux 2.6.16, glibc 2.4. faccessat2() Linux 5.8. NOTES Attention : Utiliser ces appels pour verifier si un utilisateur a le droit, par exemple, d'ouvrir un fichier avant d'effectuer reellement l'ouverture avec open(2), risque de creer un trou de securite. En effet, l'utilisateur peut exploiter le petit intervalle de temps entre la verification et l'acces pour modifier le fichier. Pour cette raison, l'utilisation de cet appel systeme devrait etre evitee (dans cet exemple, une alternative plus sure serait de basculer temporairement l'identifiant effectif de l'utilisateur vers l'identifiant reel et d'appeler open(2)). La fonction access() dereference toujours les liens symboliques. Si vous avez besoin de verifier les droits sur un lien symbolique, utilisez faccessat(2) avec l'attribut AT_SYMLINK_NOFOLLOW. Ces appels renvoient une erreur si l'un des types d'acces de mode est refuse, meme si d'autres types indiques dans mode sont autorises. Un fichier n'est accessible que si les permissions de chacun des repertoires du prefixe du chemin permettent les recherches (c'est-a-dire l'execution). Si un repertoire est inaccessible, alors l'appel a access() echouera, sans tenir compte des permissions du fichier lui-meme. Seuls les bits d'acces sont verifies et non le type ou le contenu du fichier. Ainsi, l'autorisation d'ecriture dans un repertoire indique probablement la possibilite d'y creer des fichiers et non d'y ecrire comme dans un fichier. De meme, un fichier DOS peut etre considere comme executable, alors que l'appel execve(2) echouera toujours. Ces appels peuvent fonctionner incorrectement sur un serveur NFSv2 si les correspondances d'UID sont activees, car ces correspondances sont gerees par le serveur et masquees au client qui effectue les verifications d'autorisation. Ces verifications sont effectuees sur le serveur pour les versions 3 et superieures de NFS. Des problemes similaires peuvent survenir avec les montages FUSE. BOGUES L'appel systeme faccessat() du noyau Linux ne prenant pas en charge le parametre argument, la fonction enveloppe faccessat() fournie dans la glibc 2.32 et anterieure emule la fonctionnalite necessaire en utilisant une combinaison de l'appel systeme faccessat() et de fstatat(2). Mais cette emulation ne prend pas en charge les ACL (listes de controle d'acces). A partir de la glibc 2.33, la fonction enveloppe evite ce bogue en utilisant l'appel systeme faccessat2() la ou il est fourni par le noyau sous-jacent. Dans Linux 2.4 (et auparavant) les tests X_OK sont geres de facon bizarre pour le superutilisateur. Si toutes les categories de permission d'execution sont desactivees pour un fichier (n'etant pas un repertoire), access() ne renvoie -1 que si le mode est juste X_OK ; si R_OK ou W_OK est egalement precise dans le mode, access() renvoie 0 pour ce fichier. Les premiers Linux 2.6 (jusqu'a Linux 2.6.3) se comportaient de la meme facon que Linux 2.4. Avant Linux 2.6.20, ces appels ignoraient l'effet de l'attribut MS_NOEXEC s'il etait utilise pour monter le systeme de fichiers sous-jacent (avec mount(2)). Depuis Linux 2.6.20, l'attribut MS_NOEXEC est pris en compte. VOIR AUSSI chmod(2), chown(2), open(2), setgid(2), setuid(2), stat(2), euidaccess(3), credentials(7), path_resolution(7), symlink(7) TRADUCTION La traduction francaise de cette page de manuel a ete creee par Christophe Blaess , Stephan Rafin , Thierry Vignaud , Francois Micaux, Alain Portal , Jean-Philippe Guerard , Jean-Luc Coulon (f5ibh) , Julien Cristau , Thomas Huriaux , Nicolas Francois , Florentin Duneau , Simon Paillard , Denis Barbier , David Prevot et Jean-Philippe MENGUAL Cette traduction est une documentation libre ; veuillez vous reporter a la GNU General Public License version 3 concernant les conditions de copie et de distribution. Il n'y a aucune RESPONSABILITE LEGALE. Si vous decouvrez un bogue dans la traduction de cette page de manuel, veuillez envoyer un message a . Pages du manuel de Linux 6.06 1 janvier 2024 access(2)