Access Control List (ACL): Definition, Types, Examples

What is an Access Control List (ACL)?

An Access Control List (ACL) is a data structure attached to a resource (file, directory, network device, S3 object) that explicitly enumerates which users or groups have which permissions on that resource. ACLs are one of the oldest and most fundamental access-control mechanisms in computing — used by Unix file systems, Windows NTFS, network routers, AWS S3, and many other systems.

An ACL conceptually answers the question "for resource X, who can do what?" This is the inverse of capability-based security, which asks "for user Y, what can they access?"

ACL anatomy

A typical ACL is a list of Access Control Entries (ACEs). Each ACE specifies:

• Subject: who the entry applies to (user, group, role)
• Permission(s): what action(s) are granted or denied (read, write, execute, delete)
• Decision: allow or deny
• Optional conditions: time-of-day, source IP, etc.

# Example: NFSv4 / POSIX ACL
user::rwx
user:alice:rw-
group::r-x
group:engineering:rwx
other::r--

Types of ACLs

ACL vs RBAC vs ABAC

Modern systems often combine ACLs (for special cases) with RBAC (for the bulk of users).

POSIX file system ACLs

Traditional Unix permissions are limited (one user, one group, one "other" class). POSIX ACLs extend this:

# Set permissions for individual user
setfacl -m u:alice:rw file.txt

# Set for group
setfacl -m g:engineering:r file.txt

# View ACL
getfacl file.txt

# Default ACL on directory (inherited by new files)
setfacl -d -m u:alice:rw /var/data

Network ACLs

Used in routers and firewalls to filter traffic. Each rule specifies:

• Source/destination IP (or range)
• Source/destination port
• Protocol (TCP, UDP, ICMP)
• Action (allow/deny)

# Cisco-style ACL
access-list 100 permit tcp 10.0.0.0 0.0.0.255 any eq 80
access-list 100 permit tcp 10.0.0.0 0.0.0.255 any eq 443
access-list 100 deny ip any any

AWS Network ACLs (NACLs) work similarly at the subnet level; Security Groups are the instance-level equivalent.

AWS S3 ACLs

S3 supports ACLs on buckets and objects, but AWS now recommends bucket policies + IAM for most cases. ACLs are still useful for:

• Granting cross-account access to specific objects
• Backwards compatibility with legacy systems
• Granting access to AWS log delivery service

{
  "Owner": { "ID": "..." },
  "Grants": [
    { "Grantee": { "ID": "..." }, "Permission": "FULL_CONTROL" },
    { "Grantee": { "URI": "http://acs.amazonaws.com/groups/global/AllUsers" }, "Permission": "READ" }
  ]
}

For new buckets, AWS now defaults to disabling ACLs (S3 Object Ownership = Bucket owner enforced).

ACL evaluation order

When multiple ACEs match a request, evaluation order matters. Common patterns:

• First match wins: traverse list top-to-bottom; first applicable rule decides. Used in network ACLs.
• Deny overrides allow: if any rule denies, request is denied even if others allow. Used in NTFS, Active Directory.
• Default deny: if no rule matches, deny the request. Standard secure default.

ACL best practices

• Start with default deny. Whitelist what's allowed; everything else denied.
• Least privilege. Don't grant FULL_CONTROL when READ suffices.
• Use groups, not individuals. ACLs with 200 individual user entries are unmanageable.
• Audit regularly. Stale entries accumulate; review quarterly.
• Document why each entry exists. Six months later, no one remembers.
• Prefer RBAC for bulk access. ACLs are for exceptions and special cases.
• Test rule changes carefully. Network ACLs can lock you out of your own systems.
• Watch for "deny all" misorder. If deny any any is first, everything fails.

Common ACL pitfalls

• ACL sprawl. Hundreds of entries on a single resource. Refactor to groups + RBAC.
• Inconsistent ACLs across resources. Same logical group has different permissions on different resources.
• Forgotten public-access ACLs. S3 buckets accidentally world-readable from old ACL entries.
• Default ACL not inherited. New files don't get expected permissions.
• Network ACL evaluation order. Adding new rule above broader deny silently breaks production.
• ACL vs effective permissions confusion. Multiple sources (ACL + bucket policy + IAM) — debugging requires evaluating all.

FAQ: Access Control Lists

What's the difference between ACL and RBAC?

ACL: per-resource list of who can do what. RBAC: per-role permissions, users assigned roles. RBAC scales better; ACL is more granular.

Should I use S3 ACLs?

Generally no. AWS recommends bucket policies + IAM. S3 ACLs are now disabled by default on new buckets. Use them only for cross-account or log-delivery cases.

What's the difference between AWS Security Group and NACL?

Security Group: stateful, instance-level. NACL: stateless, subnet-level. SGs apply allow rules; NACLs apply allow + deny.

Why do my POSIX ACLs not apply?

File system must support ACLs (most modern Linux file systems do). Mount with acl option if not enabled. setfacl won't work on tmpfs by default.

Can ACLs be too permissive?

Yes — over-permissive ACLs are a top cloud breach vector. Public S3 buckets, world-readable home directories, etc.

How do I audit existing ACLs?

POSIX: find / -exec getfacl {} \;. AWS: AWS Config + Trusted Advisor. Network: device-specific commands.

Do ACLs slow down systems?

Marginally. Each access check evaluates the list. Long ACLs (thousands of entries) measurably slow file operations and packet filtering.

Test ACL-protected APIs with LoadFocus

LoadFocus runs JMeter and k6 scripts that exercise authentication + authorization paths from 25+ regions, surfacing ACL misconfigurations under load. Sign up free at loadfocus.com/signup.