ACCESS(2)

✨ ACCESS — checking if a file is even accessible bestie ✨

ok so this is the manual page for access(2), from the System Calls Manual, and it's genuinely one of those pages where the tea is scalding (scroll to SECURITY CONSIDERATIONS, you'll see 💀). Sit down, hydrate, let's go.

---

🌸 NAME 🌸

access, eaccess, faccessat — check accessibility of a file

---

🎀 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 🦋

So the access() and eaccess() system calls check the accessibility of the file named by the path argument, for the access permissions indicated by the mode argument. Yes, both. They're sisters, not twins, and we'll get to the difference in a sec 👀

The value of mode is either:

• the bitwise-inclusive OR of the access permissions you wanna check — 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 info, go read the “File Access Permission” section of intro(2). It's giving required reading, but like, in a fun way.

Now the plot twist 🫢 — the eaccess() system call uses the effective user ID and the group access list to authorize the request. Meanwhile access() 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. That's it, that's the whole difference. Real vs effective, bestie.

And then there's faccessat(), which is equivalent to access() except in the case where path specifies a relative path. In that case, the file whose accessibility is being determined is located relative to the directory associated with the file descriptor fd instead of the current working directory. Slay, relative resolution.

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(). Cute.

Values for flag are constructed by a bitwise-inclusive OR of flags from this 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().

🚨 Lowkey important warning zone: 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. Same deal for R_OK and W_OK. The vibe check passing does not mean the bits are there, iykyk.

---

🌈 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.

It's giving binary. Either we're good or we're sobbing. 😭

---

💜 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.
• [EINTEGRITY] — Corrupted data was detected while reading from 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_FDCWD nor 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_FDCWD nor a file descriptor associated with a directory.

---

👑 SEE ALSO 👑

chmod(2), intro(2), stat(2)

Go read them, they're the friend group. 🫶

---

⭐ STANDARDS ⭐

• The access() system call is expected to conform to ISO/IEC 9945-1:1990 (“POSIX.1”).
• The faccessat() system call follows The Open Group Extended API Set 2 specification.

Certified, licensed, official. We love a compliant icon.

---

🧚 HISTORY 🧚

• The access() function appeared in Version 7 AT&T UNIX. Ancient. Historic. Iconic.
• The faccessat() system call appeared in FreeBSD 8.0.

---

💀 SECURITY CONSIDERATIONS 💀

ok sit down. breathe. this is the part.

The access() system call is a potential security hole due to race conditions and should never be used. Not "use carefully". Not "use with caution". Never. No cap. 🔥

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. So like... also be careful with her. 🙈

That said — access() remains useful for providing clues to users as to whether operations make sense for particular filesystem objects. Example given: a 'delete' menu item only highlighted in a writable folder... which avoids 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).

So it's a menace for security and also kinda handy for UI. Both things are true. Main character with a dark side. 💅

---

Anyways bestie, that's the whole page — brought to you by the Debian crew, dated March 30, 2020, from the System Calls Manual. Go fix your race conditions, ily, mwah 🎀✨