Provided by: manpages-fr-dev_3.57d1p1-1_all bug

NOM
       access - Vérifier les permissions d'accès à un fichier de l'utilisateur réel


SYNOPSIS
       #include <unistd.h>

       int access(const char *pathname, int mode);


DESCRIPTION
       access()  vérifie  si  le  processus  appelant  peut accéder au fichier pathname. Si pathname est un lien
       symbolique, il est déréférencé.

       Le mode indique les vérifications d'accès à effectuer. Il prend la valeur F_OK ou un masque contenant  un
       OU  binaire  d'une  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 autorise respectivement la lecture, l'écriture et l'exécution.

       Le test est effectué avec les UID et GID réels du processus appelant, plutôt qu'avec  les  IDs  effectifs
       qui  sont  utilisés  lorsque  l'on  tente  une  opération (comme open(2)) sur le fichier. Ceci permet aux
       programmes Set-UID de déterminer les autorisations de l'utilisateur ayant invoqué le programme.

       Si le processus appelant est privilégié (c'est-à-dire son UID réel est zéro), alors une vérification X_OK
       réussit pour un fichier régulier si l'exécution est permise pour l'utilisateur propriétaire, le groupe ou
       pour les autres.


VALEUR RENVOYÉE
       En cas de succès (toutes les permissions demandées sont autorisées, ou  mode  vaut  F_OK  et  le  fichier
       existe), 0 est renvoyé. En cas d'erreur (au moins une permission de mode est interdite, ou mode vaut F_OK
       et  le  fichier n'existe pas, ou d'autres erreurs se sont produites), -1 est renvoyé et errno contient le
       code d'erreur.


ERREURS
       access() doit échouer si :

       EACCES L'accès serait refusé au  fichier  lui‐même,  ou  il  n'est  pas  permis  de  parcourir  l'un  des
              répertoires du préfixe du chemin de pathname (consultez aussi path_resolution(7)).

       ELOOP  Trop de liens symboliques ont été rencontrés en parcourant pathname.

       ENAMETOOLONG
              pathname est trop long.

       ENOENT Un  composant  du  chemin  d'accès  pathname n'existe pas ou est un lien symbolique pointant nulle
              part.

       ENOTDIR
              Un élément du chemin d'accès pathname n'est pas un répertoire.

       EROFS  On demande une écriture sur un système de fichiers en lecture seule.

       access() peut échouer si :

       EFAULT pathname pointe en‐dehors de l'espace d'adressage accessible.

       EINVAL mode était mal indiqué.

       EIO    Une erreur d'entrée-sortie s'est produite.

       ENOMEM Pas assez de mémoire pour le noyau.

       ETXTBSY
              On a demandé l'écriture dans un fichier exécutable qui est en cours d'utilisation.


CONFORMITÉ
       SVr4, BSD 4.3, POSIX.1-2001.


NOTES
       Attention : Utiliser access() pour vérifier si un utilisateur  a  le  droit,  par  exemple,  d'ouvrir  un
       fichier  avant  d'effectuer  réellement l'ouverture avec open(2), risque de créer un trou de sécurité. En
       effet, l'utilisateur peut exploiter le petit intervalle de temps entre la vérification  et  l'accès  pour
       modifier  le fichier. Pour cette raison, l'utilisation de cet appel système devrait être évitée (dans cet
       exemple,  une  alternative  plus  sûre  serait  de  basculer  temporairement  l'identifiant  effectif  de
       l'utilisateur vers l'identifiant réel et d'appeler open(2)).

       La  fonction  access()  déréférence  toujours  les liens symboliques. Si vous avez besoin de vérifier les
       droits sur un lien symbolique, utilisez faccessat(2) avec l'attribut AT_SYMLINK_NOFOLLOW.

       access() renvoie une erreur si l'un des types d'accès de mode est refusé, même si d'autres types indiqués
       dans mode sont autorisés.

       Si le processus appelant a les privilèges suffisants (c'est-à-dire  est  superutilisateur),  POSIX.1-2001
       permet  à  une implémentation d'indiquer un succès pour X_OK même si le fichier n'a aucun bit d'exécution
       positionné.

       Un fichier n'est accessible que si les permissions  de  chacun  des  répertoires  du  préfixe  du  chemin
       pathname  permet  les  recherches  (c'est-à-dire  l'exécution).  Si un répertoire est inaccessible, alors
       l'appel à access() échouera, sans tenir compte des permissions du fichier lui-même.

       Seuls les bits d'accès sont vérifiés, et non le contenu du fichier. Ainsi, l'autorisation d'écriture dans
       un répertoire indique la possibilité d'y créer des fichiers et non d'y écrire comme dans un  fichier.  De
       même,  un  fichier  DOS  peut  être  considéré  comme  exécutable,  alors  que l'appel execve(2) échouera
       évidemment.

       access() peut fonctionner incorrectement sur un serveur NFSv2 si les correspondances d'UID sont activées,
       car ces correspondances sont gérées par le serveur, et masquées au client qui effectue les  vérifications
       d'autorisation.  Ces vérifications sont effectuées sur le serveur pour les versions NFSv3 et supérieures.
       Des problèmes similaires peuvent survenir avec les montages FUSE.


BOGUES
       Dans le noyau 2.4 (et auparavant) les tests X_OK sont gérés de façon bizarre pour le superutilisateur. Si
       toutes les catégories de permission  d'exécution  sont  désactivées  pour  un  fichier  (n'étant  pas  un
       répertoire), access() ne renvoie -1 que si le mode est juste X_OK ; si R_OK ou W_OK est également précisé
       dans  le mode, access() renvoyait 0 pour ce fichier. Les premier noyaux 2.6 (jusqu'à la version 2.6.3) se
       comportaient de la même façon que les noyaux 2.4.

       Dans les noyaux antérieurs à 2.6.20, access() ignorait l'effet de l'attribut MS_NOEXEC s'il était utilisé
       pour monter le système de fichiers correspondant (avec mount(2)). Depuis Linux 2.6.20, access() prend  en
       compte cet attribut.


VOIR AUSSI
       chmod(2),  chown(2), faccessat(2), open(2), setgid(2), setuid(2), stat(2), euidaccess(3), credentials(7),
       path_resolution(7)


COLOPHON
       Cette page fait partie de la publication 3.57 du projet man-pages Linux. Une description du projet et des
       instructions    pour    signaler    des    anomalies    peuvent     être     trouvées     à     l'adresse
       http://www.kernel.org/doc/man-pages/.


TRADUCTION
       Depuis 2010, cette traduction est maintenue à l'aide de l'outil po4a <http://po4a.alioth.debian.org/> par
       l'équipe de traduction francophone au sein du projet perkamon <http://perkamon.alioth.debian.org/>.

       Christophe       Blaess       <http://www.blaess.fr/christophe/>      (1996-2003),      Alain      Portal
       <http://manpagesfr.free.fr/> (2003-2006).  Julien  Cristau  et  l'équipe  francophone  de  traduction  de
       Debian (2006-2009).

       Veuillez  signaler  toute erreur de traduction en écrivant à <debian-l10n-french@lists.debian.org> ou par
       un rapport de bogue sur le paquet manpages-fr.

       Vous pouvez toujours avoir accès à la version anglaise de ce document en utilisant la commande « man -L C
       <section> <page_de_man> ».

Linux                                           13 septembre 2013                                      ACCESS(2)