1 .\" This manpage is Copyright (C) 1992 Drew Eckhardt;
2 .\" and Copyright (C) 1993 Michael Haardt, Ian Jackson.
3 .\" and Copyright (C) 2004, 2006, 2007, 2014 Michael Kerrisk <mtk.manpages@gmail.com>
5 .\" SPDX-License-Identifier: Linux-man-pages-copyleft
7 .\" Modified 1993-07-21 Rik Faith (faith@cs.unc.edu)
8 .\" Modified 1994-08-21 by Michael Chastain (mec@shell.portal.com):
9 .\" Removed note about old kernel (pre-1.1.44) using wrong id on path.
10 .\" Modified 1996-03-18 by Martin Schulze (joey@infodrom.north.de):
11 .\" Stated more clearly how it behaves with symbolic links.
12 .\" Added correction due to Nick Duffek (nsd@bbc.com), aeb, 960426
13 .\" Modified 1996-09-07 by Michael Haardt:
14 .\" Restrictions for NFS
15 .\" Modified 1997-09-09 by Joseph S. Myers <jsm28@cam.ac.uk>
16 .\" Modified 1998-01-13 by Michael Haardt:
17 .\" Using access is often insecure
18 .\" Modified 2001-10-16 by aeb
19 .\" Modified 2002-04-23 by Roger Luethi <rl@hellgate.ch>
20 .\" Modified 2004-06-23 by Michael Kerrisk
21 .\" 2007-06-10, mtk, various parts rewritten, and added BUGS section.
23 .TH access 2 (date) "Linux man-pages (unreleased)"
25 access, faccessat, faccessat2 \- check user's permissions for a file
28 .RI ( libc ", " \-lc )
31 .B #include <unistd.h>
33 .BI "int access(const char *" pathname ", int " mode );
35 .BR "#include <fcntl.h>" " /* Definition of " AT_* " constants */"
36 .B #include <unistd.h>
38 .BI "int faccessat(int " dirfd ", const char *" pathname ", int " \
39 mode ", int " flags );
40 /* But see C library/kernel differences, below */
42 .BR "#include <fcntl.h>" " /* Definition of " AT_* " constants */"
43 .BR "#include <sys/syscall.h>" " /* Definition of " SYS_* " constants */"
44 .B #include <unistd.h>
46 .B int syscall(SYS_faccessat2,
47 .BI " int " dirfd ", const char *" pathname ", int " mode \
52 Feature Test Macro Requirements for glibc (see
53 .BR feature_test_macros (7)):
59 _POSIX_C_SOURCE >= 200809L
65 checks whether the calling process can access the file
69 is a symbolic link, it is dereferenced.
73 specifies the accessibility check(s) to be performed,
74 and is either the value
76 .\" F_OK is defined as 0 on every system that I know of.
77 or a mask consisting of the bitwise OR of one or more of
78 .BR R_OK ", " W_OK ", and " X_OK .
80 tests for the existence of the file.
81 .BR R_OK ", " W_OK ", and " X_OK
82 test whether the file exists and grants read, write, and
83 execute permissions, respectively.
85 The check is done using the calling process's
87 UID and GID, rather than the effective IDs as is done when
88 actually attempting an operation (e.g.,
91 Similarly, for the root user, the check uses the set of
92 permitted capabilities rather than the set of effective
93 capabilities; and for non-root users, the check uses an empty set
96 This allows set-user-ID programs and capability-endowed programs
97 to easily determine the invoking user's authority.
100 does not answer the "can I read/write/execute this file?" question.
101 It answers a slightly different question:
102 "(assuming I'm a setuid binary) can
103 .I the user who invoked me
104 read/write/execute this file?",
105 which gives set-user-ID programs the possibility to
106 prevent malicious users from causing them to read files
107 which users shouldn't be able to read.
109 If the calling process is privileged (i.e., its real UID is zero),
112 check is successful for a regular file if execute permission
113 is enabled for any of the file owner, group, or other.
116 operates in exactly the same way as
118 except for the differences described here.
120 If the pathname given in
122 is relative, then it is interpreted relative to the directory
123 referred to by the file descriptor
125 (rather than relative to the current working directory of
126 the calling process, as is done by
128 for a relative pathname).
138 is interpreted relative to the current working
139 directory of the calling process (like
149 is constructed by ORing together zero or more of the following values:
152 Perform access checks using the effective user and group IDs.
155 uses the real IDs (like
158 .BR AT_EMPTY_PATH " (since Linux 5.8)"
161 is an empty string, operate on the file referred to by
163 (which may have been obtained using the
169 can refer to any type of file, not just a directory.
174 the call operates on the current working directory.
175 This flag is Linux-specific; define
177 to obtain its definition.
179 .B AT_SYMLINK_NOFOLLOW
182 is a symbolic link, do not dereference it:
183 instead return information about the link itself.
187 for an explanation of the need for
193 given above corresponds to POSIX.1 and
194 to the implementation provided by glibc.
195 However, the glibc implementation was an imperfect emulation (see BUGS)
196 that papered over the fact that the raw Linux
198 system call does not have a
201 To allow for a proper implementation, Linux 5.8 added the
203 system call, which supports the
205 argument and allows a correct implementation of the
209 On success (all requested permissions granted, or
213 and the file exists), zero is returned.
214 On error (at least one bit in
216 asked for a permission that is denied, or
220 and the file does not exist, or some other error occurred),
223 is set to indicate the error.
227 The requested access would be denied to the file, or search permission
228 is denied for one of the directories in the path prefix of
231 .BR path_resolution (7).)
241 nor a valid file descriptor.
245 points outside your accessible address space.
249 was incorrectly specified.
253 Invalid flag specified in
257 An I/O error occurred.
260 Too many symbolic links were encountered in resolving
270 does not exist or is a dangling symbolic link.
273 Insufficient kernel memory was available.
276 A component used as a directory in
278 is not, in fact, a directory.
285 is a file descriptor referring to a file other than a directory.
288 Write permission was requested to a file that has the immutable flag set.
290 .BR ioctl_iflags (2).
293 Write permission was requested for a file on a read-only filesystem.
296 Write access was requested to an executable which is being
299 If the calling process has appropriate privileges (i.e., is superuser),
300 POSIX.1-2001 permits an implementation to indicate success for an
302 check even if none of the execute file permission bits are set.
303 .\" HPU-UX 11 and Tru64 5.1 do this.
304 Linux does not do this.
306 .SS C library/kernel differences
309 system call takes only the first three arguments.
313 .B AT_SYMLINK_NOFOLLOW
314 flags are actually implemented within the glibc wrapper function for
316 If either of these flags is specified, then the wrapper function employs
318 to determine access permissions, but see BUGS.
321 On older kernels where
323 is unavailable (and when the
326 .B AT_SYMLINK_NOFOLLOW
327 flags are not specified),
328 the glibc wrapper function falls back to the use of
332 is a relative pathname,
333 glibc constructs a pathname based on the symbolic link in
335 that corresponds to the
350 SVr4, 4.3BSD, POSIX.1-2001.
360 Using these calls to check if a user is authorized to, for example,
361 open a file before actually doing so using
363 creates a security hole, because the user might exploit the short time
364 interval between checking and opening the file to manipulate it.
365 .BR "For this reason, the use of this system call should be avoided" .
366 (In the example just described,
367 a safer alternative would be to temporarily switch the process's
368 effective user ID to the real ID and then call
372 always dereferences symbolic links.
373 If you need to check the permissions on a symbolic link, use
376 .BR AT_SYMLINK_NOFOLLOW .
378 These calls return an error if any of the access types in
380 is denied, even if some of the other access types in
384 A file is accessible only if the permissions on each of the
385 directories in the path prefix of
387 grant search (i.e., execute) access.
388 If any directory is inaccessible, then the
390 call fails, regardless of the permissions on the file itself.
392 Only access bits are checked, not the file type or contents.
393 Therefore, if a directory is found to be writable,
394 it probably means that files can be created in the directory,
395 and not that the directory can be written as a file.
396 Similarly, a DOS file may be reported as executable, but the
398 call will still fail.
401 may not work correctly on NFSv2 filesystems with UID mapping enabled,
402 because UID mapping is done on the server and hidden from the client,
403 which checks permissions.
404 (NFS versions 3 and higher perform the check on the server.)
405 Similar problems can occur to FUSE mounts.
408 Because the Linux kernel's
410 system call does not support a
414 wrapper function provided in glibc 2.32 and earlier
415 emulates the required functionality using
420 However, this emulation does not take ACLs into account.
421 Starting with glibc 2.33, the wrapper function avoids this bug
424 system call where it is provided by the underlying kernel.
426 In Linux 2.4 (and earlier) there is some strangeness in the handling of
429 If all categories of execute permission are disabled
430 for a nondirectory file, then the only
432 test that returns \-1 is when
444 returns 0 for such files.
445 .\" This behavior appears to have been an implementation accident.
446 Early Linux 2.6 (up to and including Linux 2.6.3)
447 also behaved in the same way as Linux 2.4.
450 these calls ignored the effect of the
452 flag if it was used to
454 the underlying filesystem.
455 Since Linux 2.6.20, the
467 .BR path_resolution (7),