Provided by: manpages-fr-dev_3.32d0.2p4-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  spécifie  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 rels 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),  0
       est  renvoyé.  En  cas  d'erreur  (au  moins une permission de mode est
       interdite 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 spécifié.

       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 spécifié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 NFS 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.

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.32  du  projet  man-pages
       Linux.  Une description du projet et des instructions pour signaler des
       anomalies      peuvent      être       trouvées       à       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

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

       Christophe Blaess  <URL:http://www.blaess.fr/christophe/>  (1996-2003),
       Alain   Portal   <URL: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> ».