ACL_GET_FILE(3)

💅 ACL_GET_FILE — get an ACL by filename

okay bestie, sit DOWN, because we're doing file ACLs and this one is genuinely so useful. this is the Library Functions Manual page for acl_get_file(3), and yes it lives in the Linux Access Control Lists library.

---

🌸 LIBRARY

Linux Access Control Lists library (libacl, -lacl). link it and you're golden 🫶

---

✨ SYNOPSIS ✨

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

acl_t
acl_get_file(const char *path_p, acl_type_t type);

acl_t
acl_get_file_at(int dirfd, const char *path_p, int at_flags,
    acl_type_t type);

---

🦋 DESCRIPTION

so the whole vibe of acl_get_file() is: you give it a path, it gives you the ACL. specifically it retrieves the access ACL associated with a file or directory, OR the default ACL associated with a directory. the pathname for the file or directory goes in the argument path_p. and here's the cute part — if path_p is a symbolic link, acl_get_file() does not care about the link itself, it returns info about the file or directory the link refers to. dereference slay 💅

the ACL gets placed into working storage and acl_get_file() hands you a pointer to that storage.

heads up bestie: to read an ACL from an object, a process must have read access to the object's attributes. no read access, no ACL, periodt.

the value of the argument type is what decides whether you get the access ACL or the default ACL for path_p:

• if type is ACL_TYPE_ACCESS → you get the access ACL of path_p.
• if type is ACL_TYPE_DEFAULT → you get the default ACL of path_p.
• if type is ACL_TYPE_DEFAULT and there is no default ACL associated with the directory path_p → you get an ACL containing zero ACL entries. yes, an empty one. it's giving "nothing to see here" 🙈
• if type specifies a type of ACL that cannot be associated with path_p → the function fails. no cap.

also, this function may cause memory to be allocated. so when you're done with the new ACL, be a good citizen and free any releasable memory by calling acl_free(3) with the (void*)acl_t returned by acl_get_file() as an argument. clean up after yourself, it's the main character thing to do ✨

🎀 acl_get_file_at()

acl_get_file_at() operates in exactly the same way as acl_get_file(), except for the differences described right here. think of it as the glow-up version with extra control:

• 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, like acl_get_file() does. lowkey a whole different starting point 🗺️
• 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_get_file()). so back to normal behavior, iconic.
• if path_p is absolute, then dirfd is ignored. sorry dirfd, you're not the moment.

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

• 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, and the behavior of acl_get_file_at() is similar to that of acl_get_fd(). versatile queen 👑
• 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. links don't have ACLs, bestie, it's just the rules 😭

---

🔥 RETURN VALUE

on success, the acl_get_file() and acl_get_file_at() functions return a pointer to the working storage. yay! 🎉

on error, a value of (acl_t)NULL is returned, and errno is set appropriately. that's the sad path, and you will be checking it.

---

💀 ERRORS

if any of the following conditions occur, the acl_get_file() and acl_get_file_at() functions return a value of (acl_t)NULL and set errno to the corresponding value:

• [EACCES] — Search permission is denied for a component of the path prefix, or the object exists and the process does not have appropriate access rights.

Argument type specifies a type of ACL that cannot be associated with path_p.

• [EBADF] — The argument path_p is relative but the argument dirfd is neither AT_FDCWD nor a valid file descriptor.
• [EINVAL] — The argument type is not ACL_TYPE_ACCESS or ACL_TYPE_DEFAULT.

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.
• [ENOMEM] — The ACL working storage requires more memory than is allowed by the hardware or system-imposed memory management constraints.
• [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.

not all of these are your fault, bestie. some file systems just don't support ACLs and there's nothing you can do about it. vibe check failed, move on 💜

---

🌈 STANDARDS

IEEE Std 1003.1e draft 17 (“POSIX.1e”, abandoned). rip to that draft, it really tried 😔

Function acl_get_file_at() is a Linux specific extension. iykyk.

---

⭐ SEE ALSO

acl_free(3), acl_get_entry(3), acl_get_fd(3), acl_set_file(3), acl(5)

---

🫶 AUTHOR

Derived from the FreeBSD manual pages written by Robert N M Watson <rwatson@FreeBSD.org>, and adapted for Linux by Andreas Gruenbacher <andreas.gruenbacher@gmail.com>. thank you for your service, legends 💖

---

and that's the whole page, bestie! this one came from the Linux ACL crew and it's dated June 5, 2026. go get those ACLs, slay, and remember to acl_free(3) when you're done 🎀✨🦋