What Are Access Control Lists (ACLs) in an Operating System?
Learn what access control lists are in an operating system, how they differ from permission bits, with a worked interview example.
Expected Interview Answer
An access control list (ACL) is a per-object list of entries, each pairing a specific user or group with the permissions they hold on that object, giving finer-grained control than the traditional owner/group/other permission bits found on most Unix-style filesystems.
Where classic Unix permission bits only let you grant one set of rights to the owner, one to a single group, and one to everyone else, an ACL lets an administrator attach arbitrary many entries to a single file or directory — for example, granting read-write to user alice, read-only to group interns, and no access to everyone else, all on the same file. Each ACL entry typically specifies a subject (user or group) and a permission set (read, write, execute, or more granular rights on systems like NTFS or NFSv4), and the kernel walks the list on every access request until it finds a matching entry or falls through to a default deny. ACLs are stored as extended metadata alongside the object — as extended attributes on Linux (getfacl/setfacl), or as a security descriptor on Windows — so they persist with the file across operations. The tradeoff is expressiveness versus complexity: ACLs make it possible to model organizational access precisely, but a poorly maintained ACL can become hard to audit compared to the far simpler owner/group/other model.
- Grants precise per-user or per-group permissions on a single object
- Goes beyond the single owner/group/other limitation of classic Unix bits
- Persists as extended metadata alongside the file or directory
- Supports fine-grained enterprise access models on shared resources
AI Mentor Explanation
An ACL is like a stadium’s VIP box booking sheet for a single match: rather than one blanket rule for everyone, the sheet lists named individuals and groups one by one — the sponsor’s guests get full lounge access, the volunteer stewards get corridor-only access, and the general public gets none — all attached to that one box. The gatekeeper checks the sheet entry by entry for each person arriving, falling back to denial if no entry matches, which is exactly how the kernel walks an ACL on a file.
Step-by-Step Explanation
Step 1
Object gains an ACL
A file or directory is assigned a list of entries, each pairing a specific user or group with a permission set, beyond the basic owner/group/other bits.
Step 2
Access request arrives
A process attempts to open, read, or write the object under a given user identity.
Step 3
Kernel walks the ACL
The kernel checks the requesting identity against each ACL entry in order, looking for a matching user or group rule.
Step 4
Grant or deny
If a matching entry grants the requested permission the operation proceeds; otherwise the kernel falls through to a default deny.
What Interviewer Expects
- Clear contrast between ACLs and the classic owner/group/other bits
- Understanding that ACLs allow multiple named users/groups on one object
- Awareness of how ACLs are stored (extended attributes, security descriptors)
- Recognition of the audit/complexity tradeoff versus simple permission bits
Common Mistakes
- Confusing ACLs with the standard rwx permission bits
- Thinking ACLs only support one user entry per file
- Not knowing ACLs are stored as extended metadata, not inline in the file content
- Assuming ACLs have no maintenance or audit cost compared to simple permissions
Best Answer (HR Friendly)
“An access control list is a more detailed permission system attached to a specific file or folder — instead of just one rule for the owner, one for a group, and one for everyone else, it lets you name individual people or groups and give each of them their own exact level of access on that same resource. It is what lets organizations model real-world access needs precisely, though it does take more effort to keep tidy than the simple owner/group/other model.”
Code Example
#include <sys/acl.h>
#include <stdio.h>
void print_acl(const char *path) {
acl_t acl = acl_get_file(path, ACL_TYPE_ACCESS);
if (acl == NULL) {
perror("acl_get_file");
return;
}
char *text = acl_to_text(acl, NULL);
if (text != NULL) {
printf("ACL for %s:\n%s\n", path, text);
acl_free(text);
}
acl_free(acl);
}Follow-up Questions
- How does a POSIX ACL differ from an NTFS security descriptor?
- What happens when both permission bits and an ACL are present on the same file?
- How would you audit an ACL that has grown too complex over time?
- What is a default ACL and how does it affect files created in a directory?
MCQ Practice
1. What limitation of classic Unix permission bits do ACLs solve?
Classic Unix bits only support a single owner rule, a single group rule, and one catch-all rule; ACLs allow many named user/group entries on one object.
2. Where are ACL entries typically stored on a Linux filesystem?
Linux ACLs are stored as extended attributes tied to the file's inode, accessible via tools like getfacl and setfacl.
3. What happens if an ACL check finds no matching entry for a requester?
When no ACL entry matches the requesting identity, the system defaults to denying the requested access.
Flash Cards
What is an ACL? — A per-object list pairing specific users or groups with their own permissions on that object.
How is an ACL different from owner/group/other bits? — It supports many named entries instead of just one owner rule, one group rule, and one catch-all rule.
Where does Linux store ACLs? — As extended attributes on the file, managed via getfacl/setfacl.
What happens with no matching ACL entry? — The kernel defaults to denying the request.