Provided by: manpages-fr-dev_3.32d0.2p4-1_all bug

NOM

       access - Verifier les permissions d'acces a un fichier de l'utilisateur
       reel

SYNOPSIS

       #include <unistd.h>

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

DESCRIPTION

       access() verifie si le  processus  appelant  peut  acceder  au  fichier
       pathname. Si pathname est un lien symbolique, il est dereference.

       Le  mode  specifie  les  verifications d'acces a 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'ecriture et l'execution.

       Le  test  est effectue avec les UID et GID r'eels du processus appelant,
       plutot qu'avec les IDs effectifs qui sont utilises lorsque  l'on  tente
       une   operation  (comme  open(2))  sur  le  fichier.  Ceci  permet  aux
       programmes Set-UID de determiner  les  autorisations  de  l'utilisateur
       ayant invoque le programme.

       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.

VALEUR RENVOY'EE

       En cas de succes (toutes les permissions demandees sont autorisees),  0
       est  renvoye.  En  cas  d'erreur  (au  moins une permission de mode est
       interdite ou d'autres erreurs se sont produites),  -1  est  renvoye  et
       errno contient le code d'erreur.

ERREURS

       access() doit echouer si :

       EACCES L'acces  serait  refuse  au  fichier  lui-meme,  ou il n'est pas
              permis de parcourir l'un des repertoires du prefixe du chemin de
              pathname (consultez aussi path_resolution(7)).

       ELOOP  Trop  de  liens  symboliques  ont  ete  rencontres en parcourant
              pathname.

       ENAMETOOLONG
              pathname est trop long.

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

       ENOTDIR
              Un element du chemin d'acces pathname n'est pas un repertoire.

       EROFS  On  demande  une  ecriture sur un systeme de fichiers en lecture
              seule.

       access() peut echouer si :

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

       EINVAL mode etait mal specifie.

       EIO    Une erreur d'entree-sortie s'est produite.

       ENOMEM Pas assez de memoire pour le noyau.

       ETXTBSY
              On a demande l'ecriture dans un fichier executable  qui  est  en
              cours d'utilisation.

CONFORMIT'E

       SVr4, BSD 4.3, POSIX.1-2001.

NOTES

       Attention :  Utiliser  access()  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  syst`eme  devrait  ^etre  'evit'ee  (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.

       access()  renvoie  une  erreur  si  l'un  des types d'acces de mode est
       refuse, meme si d'autres types specifies dans mode sont autorises.

       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.

       Un  fichier  n'est  accessible  que  si  les  permissions de chacun des
       repertoires  du  prefixe  du  chemin  pathname  permet  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 contenu du fichier.
       Ainsi,  l'autorisation  d'ecriture  dans  un  repertoire   indique   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 evidemment.

       access()  peut  fonctionner  incorrectement  sur  un serveur NFS 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.

BOGUES

       Dans le noyau 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()  renvoyait  0
       pour  ce  fichier. Les premier noyaux 2.6 (jusqu'a la version 2.6.3) se
       comportaient de la meme facon que les noyaux 2.4.

       Dans les noyaux anterieurs  a  2.6.20,  access()  ignorait  l'effet  de
       l'attribut  MS_NOEXEC  s'il  etait  utilise  pour  monter le systeme 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      etre       trouvees       a       l'adresse
       <URL:http://www.kernel.org/doc/man-pages/>.

TRADUCTION

       Depuis  2010,  cette  traduction est maintenue a l'aide de l'outil po4a
       <URL:http://po4a.alioth.debian.org/>   par   l'equipe   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'equipe francophone de traduction de Debian (2006-2009).

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

       Vous pouvez toujours avoir acces a la version anglaise de  ce  document
       en utilisant la commande << man -L C <section> <page_de_man> >>.