euidaccess(3)
β¨ euidaccess(3) β¨
okay bestie, welcome to euidaccess(3) β that's a library functions manual page, for the record, and we're about to have a whole moment about it π
πΈ NAME πΈ
euidaccess, eaccess β check the effective user's permissions for a file π«Ά
π LIBRARY π
Standard C library β that's libc, link it with -lc π
β¨ SYNOPSIS β¨
#define _GNU_SOURCE /* See feature_test_macros(7) */
#include <unistd.h>
int euidaccess(const char *path, int mode);
int eaccess(const char *path, int mode);
π« DESCRIPTION π«
So here's the tea β β euidaccess() is giving very much like access(2): it checks the permissions and the existence of the file that its argument path points at. Same energy. BUT. π
Here's where they diverge, and it's the whole plot twist: access(2) does its checks using the real user and group identifiers of the process. euidaccess()? It uses the effective identifiers instead. That's the entire vibe. That's the difference. Periodt. π
mode is a mask made up of one or more of R_OK, W_OK, X_OK, and F_OK β and they mean exactly the same things they mean for access(2). No new lore, same meanings π
And eaccess() is just a synonym for euidaccess() β it's there for compatibility with some other systems. It's the same function wearing a little alias hat π
π― RETURN VALUE π―
- On success β meaning all the requested permissions were granted β you get
zeroback. slay β¨ - On error β meaning at least one bit in
modeasked for a permission that's denied, or some other error happened β you get-1, anderrnois set to indicate the error. π
π¨ ERRORS π¨
As for access(2). That's it. Go read that page, bestie, the errors live there π
𧬠ATTRIBUTES π§¬
For an explanation of the terms used in this section, see attributes(7).
- Interface:
euidaccess(),eaccess()β Attribute: Thread safety β Value:MT-Safeπ«Ά
π°οΈ VERSIONS π°οΈ
Some other systems have an eaccess() function. that's the whole thing π
π STANDARDS π
None. Not a single one. it's giving unstandardized icon behavior π
π HISTORY π
eaccess()β glibc 2.4.
β οΈ NOTES β οΈ
Warning: using this function to check a process's permissions on a file before performing some operation based on that information leads to race conditions β because the file permissions may change between those two steps. π Generally, it is safer to just attempt the desired operation and handle any permission error that occurs. like, just do the thing and deal with it, fr fr.
Also important: this function always dereferences symbolic links. Always. No negotiation. If you need to check the permissions on a symbolic link itself, use faccessat(2) with the flags AT_EACCESS and AT_SYMLINK_NOFOLLOW. that's the move π§
π SEE ALSO π
access(2), chmod(2), chown(2), faccessat(2), open(2), setgid(2), setuid(2), stat(2), credentials(7), path_resolution(7)
okay that's the whole page, you ate that π this came to you courtesy of Linux man-pages 6.20, dated 2026-02-08 β and yes, that's euidaccess(3), no cap π mwah, go check some permissions bestie π
π¦ where this page comes from
- arch rolling: man-pages 6.20-1 Β· BSD-2-Clause AND BSD-3-Clause AND BSD-4.3TAHOE AND BSD-4-Clause-UC AND GPL-1.0-or-later AND GPL-2.0-only AND GPL-2.0-or-later AND GPL-3.0-or-later AND LGPL-3.0-linking-exception AND LGPL-3.0-or-later AND LicenseRef-Public-Domain AND LicenseRef-UltraPermissive AND Linux-man-pages-1-para AND Linux-man-pages-copyleft AND Linux-man-pages-copyleft-2-para AND Linux-man-pages-copyleft-var AND MIT AND Spencer-94
- nixpkgs unstable: man-pages 6.20
- π the page's license: Linux-man-pages-copyleft
- Copyright 2007, Michael Kerrisk <mtk.manpages@gmail.com>
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms