table of contents
| ACCESS(2) | System Calls Manual | ACCESS(2) | 
NAME¶
access, eaccess,
  faccessat —
LIBRARY¶
Standard C Library (libc, -lc)SYNOPSIS¶
#include <unistd.h>
int
  
  access(const
    char *path, int
    mode);
int
  
  eaccess(const
    char *path, int
    mode);
int
  
  faccessat(int
    fd, const char
    *path, int mode,
    int flag);
DESCRIPTION¶
Theaccess() and eaccess()
  system calls check the accessibility of the file named by the
  path argument for the access permissions indicated by
  the mode argument. The value of
  mode is either the bitwise-inclusive OR of the access
  permissions to be checked (R_OK for read permission,
  W_OK for write permission, and
  X_OK for execute/search permission), or the existence
  test (F_OK).
For additional information, see the File Access Permission section of intro(2).
The eaccess() system call uses the
    effective user ID and the group access list to authorize the request; the
    access() system call uses the real user ID in place
    of the effective user ID, the real group ID in place of the effective group
    ID, and the rest of the group access list.
The faccessat() system call is equivalent
    to access() except in the case where
    path specifies a relative path. In this case the file
    whose accessibility is to be determined is located relative to the directory
    associated with the file descriptor fd instead of the
    current working directory. If faccessat() is passed
    the special value AT_FDCWD in the
    fd parameter, the current working directory is used
    and the behavior is identical to a call to access().
    Values for flag are constructed by a bitwise-inclusive
    OR of flags from the following list, defined in
    <fcntl.h>:
AT_EACCESS- The checks for accessibility are performed using the effective user and
      group IDs instead of the real user and group ID as required in a call to
      
access(). 
Even if a process's real or effective user has appropriate
    privileges and indicates success for X_OK, the file
    may not actually have execute permission bits set. Likewise for
    R_OK and W_OK.
RETURN VALUES¶
Upon successful completion, the value 0 is returned; otherwise the value -1 is returned and the global variable errno is set to indicate the error.ERRORS¶
access(), eaccess(), or
  faccessat() will fail if:
- [
EINVAL] - The value of the mode argument is invalid.
 - [
ENOTDIR] - A component of the path prefix is not a directory.
 - [
ENAMETOOLONG] - A component of a pathname exceeded 255 characters, or an entire path name exceeded 1023 characters.
 - [
ENOENT] - The named file does not exist.
 - [
ELOOP] - Too many symbolic links were encountered in translating the pathname.
 - [
EROFS] - Write access is requested for a file on a read-only file system.
 - [
ETXTBSY] - Write access is requested for a pure procedure (shared text) file presently being executed.
 - [
EACCES] - Permission bits of the file mode do not permit the requested access, or search permission is denied on a component of the path prefix.
 - [
EFAULT] - The path argument points outside the process's allocated address space.
 - [
EIO] - An I/O error occurred while reading from or writing to the file system.
 
Also, the faccessat() system call may fail
    if:
- [
EBADF] - The path argument does not specify an absolute path
      and the fd argument is neither
      
AT_FDCWDnor a valid file descriptor. - [
EINVAL] - The value of the flag argument is not valid.
 - [
ENOTDIR] - The path argument is not an absolute path and
      fd is neither 
AT_FDCWDnor a file descriptor associated with a directory. 
SEE ALSO¶
chmod(2), intro(2), stat(2)STANDARDS¶
Theaccess() system call is expected to conform to
  IEEE Std 1003.1-1990 (“POSIX.1”). The
  faccessat() system call follows The Open Group
  Extended API Set 2 specification.
HISTORY¶
Theaccess() function appeared in
  Version 7 AT&T UNIX. The
  faccessat() system call appeared in
  FreeBSD 8.0.
SECURITY CONSIDERATIONS¶
Theaccess() system call is a potential security hole
  due to race conditions and should never be used. Set-user-ID and set-group-ID
  applications should restore the effective user or group ID, and perform
  actions directly rather than use access() to simulate
  access checks for the real user or group ID. The
  eaccess() system call likewise may be subject to races
  if used inappropriately.
access() remains useful for providing
    clues to users as to whether operations make sense for particular filesystem
    objects (e.g. 'delete' menu item only highlighted in a writable folder ...
    avoiding interpretation of the st_mode bits that the application might not
    understand -- e.g. in the case of AFS). It also allows a cheaper file
    existence test than stat(2).
| September 15, 2014 | Linux 4.9.0-9-amd64 |