Section (2) access
access, faccessat — check user_zsingle_quotesz_s permissions for a file
||const char *pathname,|
#include <fcntl.h> /* Definition of AT_* constants */ #include <unistd.h>
|const char *pathname,|
access() checks whether the
calling process can access the file
pathname is a symbolic link, it
the accessibility check(s) to be performed, and is either the
F_OK, or a mask
consisting of the bitwise OR of one or more of
F_OK tests for the existence of the file.
X_OK test whether the file exists and
grants read, write, and execute permissions,
The check is done using the calling process_zsingle_quotesz_s
real UID and GID, rather than
the effective IDs as is done when actually attempting an
operation (e.g., open(2)) on the file.
Similarly, for the root user, the check uses the set of
permitted capabilities rather than the set of effective
capabilities; and for non-root users, the check uses an empty
set of capabilities.
This allows set-user-ID programs and capability-endowed
programs to easily determine the invoking user_zsingle_quotesz_s authority.
In other words,
not answer the can I read/write/execute this file?
question. It answers a slightly different question:
(assuming I_zsingle_quotesz_m a setuid binary) can the user who invoked me
read/write/execute this file?, which gives set-user-ID
programs the possibility to prevent malicious users from
causing them to read files which users shouldn_zsingle_quotesz_t be able to
If the calling process is privileged (i.e., its real UID
is zero), then an
X_OK check is
successful for a regular file if execute permission is
enabled for any of the file owner, group, or other.
call operates in exactly the same way as
access(), except for the differences
If the pathname given in
pathname is relative, then it
is interpreted relative to the directory referred to by the
dirfd (rather than relative
to the current working directory of the calling process, as
is done by
access() for a
is the special value
pathname is interpreted
relative to the current working directory of the calling
dirfd is ignored.
constructed by ORing together zero or more of the following
Perform access checks using the effective user and group IDs. By default,
faccessat() uses the real IDs (like
pathnameis a symbolic link, do not dereference it: instead return information about the link itself.
See openat(2) for an
explanation of the need for
On success (all requested permissions granted, or
F_OK and the file exists), zero is
returned. On error (at least one bit in
mode asked for a permission
that is denied, or
F_OK and the file does not exist, or some
other error occurred), −1 is returned, and
errno is set appropriately.
faccessat() shall fail if:
The requested access would be denied to the file, or search permission is denied for one of the directories in the path prefix of
pathname. (See also path_resolution(7).)
Too many symbolic links were encountered in resolving
pathnameis too long.
A component of
pathnamedoes not exist or is a dangling symbolic link.
A component used as a directory in
pathnameis not, in fact, a directory.
Write permission was requested for a file on a read-only filesystem.
faccessat() may fail if:
pathnamepoints outside your accessible address space.
modewas incorrectly specified.
An I/O error occurred.
Insufficient kernel memory was available.
Write access was requested to an executable which is being executed.
The following additional errors can occur for
dirfdis not a valid file descriptor.
Invalid flag specified in
pathnameis relative and
dirfdis a file descriptor referring to a file other than a directory.
faccessat() was added to
Linux in kernel 2.6.16; library support was added to glibc in
Using these calls to check if a user is authorized to, for example, open a file before actually doing so using open(2) creates a security hole, because the user might exploit the short time interval between checking and opening the file to manipulate it. For this reason, the use of this system call should be avoided. (In the example just described, a safer alternative would be to temporarily switch the process_zsingle_quotesz_s effective user ID to the real ID and then call open(2).)
access() always dereferences
symbolic links. If you need to check the permissions on a
symbolic link, use
with the flag
These calls return an error if any of the access types in
mode is denied, even
if some of the other access types in
mode are permitted.
If the calling process has appropriate privileges (i.e.,
is superuser), POSIX.1-2001 permits an implementation to
indicate success for an
check even if none of the execute file permission bits are
set. Linux does not do this.
A file is accessible only if the permissions on each of
the directories in the path prefix of
pathname grant search (i.e.,
execute) access. If any directory is inaccessible, then the
access() call fails, regardless
of the permissions on the file itself.
Only access bits are checked, not the file type or contents. Therefore, if a directory is found to be writable, it probably means that files can be created in the directory, and not that the directory can be written as a file. Similarly, a DOS file may be found to be executable, but the execve(2) call will still fail.
These calls may not work correctly on NFSv2 filesystems with UID mapping enabled, because UID mapping is done on the server and hidden from the client, which checks permissions. (NFS versions 3 and higher perform the check on the server.) Similar problems can occur to FUSE mounts.
C library/kernel differences
call takes only the first three arguments. The
AT_SYMLINK_NOFOLLOW flags are actually
implemented within the glibc wrapper function for
faccessat(). If either of
these flags is specified, then the wrapper function employs
fstatat(2) to determine
On older kernels where
faccessat() is unavailable (and when the
AT_SYMLINK_NOFOLLOW flags are not
specified), the glibc wrapper function falls back to the
pathname is a
relative pathname, glibc constructs a pathname based on the
symbolic link in
/proc/self/fd that corresponds to the
In kernel 2.4 (and earlier) there is some strangeness in
the handling of
X_OK tests for
superuser. If all categories of execute permission are
disabled for a nondirectory file, then the only
access() test that returns −1 is when
mode is specified as
is also specified in
access() returns 0 for such files. Early
2.6 kernels (up to and including 2.6.3) also behaved in the
same way as kernel 2.4.
In kernels before 2.6.20, these calls ignored the effect
MS_NOEXEC flag if it was
used to mount(2) the underlying
filesystem. Since kernel 2.6.20, the
MS_NOEXEC flag is honored.
This page is part of release 4.16 of the Linux
man-pages project. A
description of the project, information about reporting bugs,
and the latest version of this page, can be found at
This manpage is Copyright (C) 1992 Drew Eckhardt;
and Copyright (C) 1993 Michael Haardt, Ian Jackson.
and Copyright (C) 2004, 2006, 2007, 2014 Michael Kerrisk <mtk.manpagesgmail.com>
Permission is granted to make and distribute verbatim copies of this
manual provided the copyright notice and this permission notice are
preserved on all copies.
Permission is granted to copy and distribute modified versions of this
manual under the conditions for verbatim copying, provided that the
entire resulting derived work is distributed under the terms of a
permission notice identical to this one.
Since the Linux kernel and libraries are constantly changing, this
manual page may be incorrect or out-of-date. The author(s) assume no
responsibility for errors or omissions, or for damages resulting from
the use of the information contained herein. The author(s) may not
have taken the same level of care in the production of this manual,
which is licensed free of charge, as they might when working
Formatted or processed versions of this manual, if unaccompanied by
the source, must acknowledge the copyright and authors of this work.
Modified 1993-07-21 Rik Faith (faithcs.unc.edu)
Modified 1994-08-21 by Michael Chastain (mecshell.portal.com):
Removed note about old kernel (pre-1.1.44) using wrong id on path.
Modified 1996-03-18 by Martin Schulze (joeyinfodrom.north.de):
Stated more clearly how it behaves with symbolic links.
Added correction due to Nick Duffek (nsdbbc.com), aeb, 960426
Modified 1996-09-07 by Michael Haardt:
Restrictions for NFS
Modified 1997-09-09 by Joseph S. Myers <jsm28cam.ac.uk>
Modified 1998-01-13 by Michael Haardt:
Using access is often insecure
Modified 2001-10-16 by aeb
Modified 2002-04-23 by Roger Luethi <rlhellgate.ch>
Modified 2004-06-23 by Michael Kerrisk
2007-06-10, mtk, various parts rewritten, and added BUGS section.