| ACCESS(2) | System Calls Manual | ACCESS(2) | 
access, faccessat —
#include <unistd.h>
int
  
  access(const
    char *path, int
    mode);
#include
  <fcntl.h>
int
  
  faccessat(int
    fd, const char
    *path, int mode,
    int flags);
access() function checks the accessibility of the
  file named by path. The
  faccessat() function checks the accessibility of the
  file named by path using fd as the
  starting point for relative pathnames. If fd is
  AT_FDCWD the current directory is used. Calling
  access() is equivalent to calling
  faccessat() with fd set to
  AT_FDCWD and flags set to 0.
The form of access to check is specified by the bitwise or of the following values for mode:
R_OKW_OKX_OKF_OKAll components of the pathname path are checked for access permissions as well.
The owner of a file has permission checked with respect to the “owner” read, write, and execute mode bits, members of the file's group other than the owner have permission checked with respect to the “group” mode bits, and all others have permissions checked with respect to the “other” mode bits.
The file descriptor fd must name a directory. Search permission is required on this directory.
The flags argument to
    faccessat() can specify the following optional
    behavior:
For access(), and
    faccessat() when the
    AT_EACCESS flag is not passed, the real user ID and
    the real group ID are used for checking permission in place of the effective
    user ID and effective group ID. This affects only set-user-ID and
    set-group-ID programs, which should not use these functions. (For other
    programs, the real and effective IDs are the same.)
For processes running with super-user privileges, these functions
    may return success for read and write checks regardless of whether read and
    write permission bits are actually set. This reflects the fact that the
    super-user may read and write all files regardless of permission settings.
    However, even for the super-user, an execute check using
    X_OK will succeed only if the target object has at
    least one of its execute permission bits set. (This does not guarantee that
    the target object can necessarily be successfully executed. See
    execve(2).)
access() and faccessat()
  functions succeed and return 0 if, at some point in the recent past, the
  target object named by path existed and its permission
  settings allowed the requested access as described above. If the requested
  access would not have been granted, the object did not exist, or the path
  lookup failed, the value -1 is returned and the value of
  errno is set to reflect what went wrong.
EACCES]EBADF]AT_FDCWD.EFAULT]EINVAL]EIO]ELOOP]ENAMETOOLONG]NAME_MAX}
      characters, or an entire path name exceeded
      {PATH_MAX} characters.ENOENT]ENOTDIR]EROFS]ETXTBSY]access() function conforms to IEEE
  Std 1003.1-1990 (“POSIX.1”).
  faccessat() function conforms to IEEE
  Std 1003.1-2008 (“POSIX.1”).
Note that faccessat() violates the
    historic convention that system calls whose names begin with `f' operate on
    file handles rather than paths. There is no equivalent to
    access() for checking access properties of an
    already-opened file.
Privileged programs that need to restrict their actions to files
    or directories properly accessible to unprivileged users
    must do this by assuming or restoring an unprivileged
    state (see seteuid(2)) when
    performing the pertinent actions. Checking in advance (with
    access() or any other method) and performing such
    actions while privileged introduces a race condition that in most cases is
    easily exploitable by even a naive adversary.
Even for non-privileged programs, the opportunity for the world to
    change after the call runs makes access() and
    faccessat() not very useful. In general only
    F_OK should be used, and that too, sparingly. The
    other checks may occasionally be useful for user interface or diagnostic
    purposes.
| January 12, 2013 | NetBSD 10.0 |