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> ».