ACL_EXTENDED_FILE(3)

💖 ACL_EXTENDED_FILE(3) 💖

okay bestie, so this is a page from the Library Functions Manual, and it's all about three little functions that go "hey, does this file have ~extra~ ACL info or not?" 🦋

---

✨ NAME ✨

acl_extended_file, acl_extended_file_at, acl_extended_file_nofollow — test for information in ACLs by file name 👑

---

📚 LIBRARY 📚

The Linux Access Control Lists library (that's libacl, and you link it with -lacl). 💅

---

🌸 SYNOPSIS 🌸

#include <sys/types.h>
#include <acl/libacl.h>

int
acl_extended_file(const char *path_p);

int
acl_extended_file_at(int dirfd, const char *path_p, int at_flags);

int
acl_extended_file_nofollow(const char *path_p);

---

💫 DESCRIPTION 💫

okay so here's the tea. acl_extended_file() returns 1 if the file or directory whose pathname you handed it in path_p is associated with an extended access ACL, or if the directory that path_p points at is associated with a default ACL. 🎀

It returns 0 if the file has neither an extended access ACL nor a default ACL. nothing. zero. dry. 💀

And if path_p is a symbolic link? then acl_extended_file() gives you info about the file or directory the link refers to — like, it follows it, no cap. 🧚

So what even is an extended ACL? it's an ACL that contains entries other than the three required entries of tag types ACL_USER_OBJ, ACL_GROUP_OBJ and ACL_OTHER. that's it, that's the definition. 🫶

and here's why that matters: if the result of acl_extended_file() for a file object is 0, then ACLs define no discretionary access rights other than those already defined by the traditional file permission bits. so like, the classic rwx bits are telling the whole story, periodt. ⭐

also, quick heads up — access to the file object may be further restricted by other mechanisms, such as Mandatory Access Control schemes. the access(2) system call can be used to check whether a given type of access to a file object would be granted. (yes, this function is not the whole vibe check, it's just one of them. 🙈)

🦋 acl_extended_file_at() 🦋

acl_extended_file_at() operates in exactly the same way as acl_extended_file(), except for the differences described here. (dramatic pause 🎭)

• If the pathname given in path_p is relative, then it is interpreted relative to the directory referred to by the file descriptor dirfd — rather than relative to the current working directory of the calling process, as is done by acl_extended_file(). main character behavior: your own base directory. 👑
• If path_p is relative and dirfd is the special value AT_FDCWD, then path_p is interpreted relative to the current working directory of the calling process (like acl_extended_file()). so basically back to normal. ✨
• If path_p is absolute, then dirfd is ignored. literally ignored. not even looking at it. 💅

The at_flags argument can either be 0, or include one or more of the following flags ORed:

• AT_EMPTY_PATH — If path_p is an empty string, operate on the file referred to by dirfd (which may have been obtained using the open(2) O_PATH flag). In this case, dirfd can refer to any type of file, not just a directory. 🎀
• AT_SYMLINK_NOFOLLOW — If path_p refers to a symbolic link, do not dereference it: instead, fail the operation and set the global variable errno to ENOTSUP. This indicates that the symbolic link cannot have ACLs. 🔥 (no follow, no problem, just an error code bestie)

🌈 acl_extended_nofollow() 🌈

The acl_extended_file_at() function operates in exactly the same way as acl_extended_file() with a dirfd value of AT_FDCWD and an at_flags value of AT_SYMLINK_NOFOLLOW. 🫶

---

👑 RETURN VALUE 👑

If successful, these functions return:

• 1 — if the file object referred to by path_p has an extended access ACL or a default ACL 🥳
• 0 — if the file object referred to by path_p has neither an extended access ACL nor a default ACL 🫥

Otherwise, the value -1 is returned and the global variable errno is set to indicate the error. 😭

---

💀 ERRORS 💀

If any of the following conditions occur, these functions return -1 and set errno to the corresponding value:

• [EACCES] — Search permission is denied for a component of the path prefix.
• [EBADF] — The argument path_p is relative but the argument dirfd is neither AT_FDCWD nor a valid file descriptor.
• [EINVAL] — An invalid flag was specified in the at_flags argument.
• [ENAMETOOLONG] — The length of the argument path_p is too long.
• [ENOENT] — The named object does not exist or the argument path_p points to an empty string.
• [ENOTDIR] — A component of the path prefix is not a directory.
  • The argument path_p is relative and the argument dirfd is a file descriptor referring to a file other than a directory.
• [ENOTSUP] — The argument at_flags includes the flag AT_SYMLINK_NOFOLLOW and path_p is a symbolic link.
  • The file system on which the file identified by path_p is located does not support ACLs, or ACLs are disabled.

ngl that last one is the "your filesystem said no ❤️" error. know it, love it, respect it. 🍓

---

📏 STANDARDS 📏

This is a non-portable, Linux specific extension to the ACL manipulation functions defined in IEEE Std 1003.1e draft 17 (“POSIX.1e”, abandoned). yeah. abandoned. it's giving ghosted. 👻

---

🔗 SEE ALSO 🔗

access(2), acl_get_file(3), acl(5)

---

✍️ AUTHOR ✍️

Written by Andreas Gruenbacher <andreas.gruenbacher@gmail.com>. iconic of him honestly. 🎀

---

and that's the whole page bestie!! 💖 this came to you from the Linux ACL crew, dated June 5, 2026 — mwah, go check your ACLs, slay, bye!! 🦋✨💅