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
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), 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.
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.44 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> ».