Linux File Permissions Weren't Enough Here's What ACLs Actually Do

Linux permissions are one of the first things you learn. chmod, chown, owner, group and others . This model has a hard limit, and when you hit it, you need something called Access Control Lists (ACLs).

The Problem With Standard Permissions

The classic Linux permission model gives you three buckets:

• Owner – the user who owns the file

• Group – a group of users

• Others – everyone else

Every file gets one set of read/write/execute flags for each bucket. Simple and sometimes completely insufficient.

Imagine this: you have a project directory. You want:

• alice to have read and write access

• bob to have read-only access

• charlie to have no access at all

With standard permissions, you cannot do this cleanly. You can only assign one owner and one group. You'd end up creating extra groups or making compromises that weaken your security.

Remember the principle of least privilege it comes in handy here.

What Are ACLs?

An Access Control List is an extended permission layer that sits on top of the standard Linux permission model.

Instead of three fixed buckets, ACLs let you define permissions for any number of specific users or groups on a single file or directory.

It's already built into most modern Linux filesystems (ext4, XFS, Btrfs) all you need to know are two commands:

• setfacl — set or modify ACL entries

• getfacl — read the current ACL on a file or directory

Seeing It in Action

Let's walk through a concrete example. Say we have a directory called project/.

First, check if ACLs are supported on your filesystem:

mount | grep acl

If you don't see acl in the options, you may need to remount with ACL support:

sudo mount -o remount,acl /

Grant alice read and write access:

setfacl -m u:alice:rw project/

Grant bob read-only access:

setfacl -m u:bob:r project/

Remove charlie's access entirely:

setfacl -m u:charlie:--- project/

Now check what you've set:

getfacl project/

You'll see output like this:

# file: project/
# owner: youruser
# group: yourgroup
user::rwx
user:alice:rw-
user:bob:r--
user:charlie:---
group::r-x
mask::rwx
other::r-x

Each line is a separate ACL entry. Clean, readable, and precise.

The mask Entry

When you set an ACL, Linux automatically adds a mask entry. This is the part that can get really confusing.

The mask defines the maximum effective permissions that any named user or group ACL entry can have. Think of it as a ceiling.

If alice has rw- but the mask is r--, her effective permission is only r-- — even though her entry says otherwise.

Mask can be set explicitly by:

setfacl -m m::rw project/

Always check the mask when permissions aren't behaving the way you expect. It's usually the culprit.

The + Sign

After setting ACLs, if you run ls -l on the file or directory, you'll notice a + at the end of the permission string:

drwxrwxr-x+ 2 youruser yourgroup 4096 May 22 10:00 project/

That + is Linux quietly telling you: "There's more here than what you see." It's a signal to run getfacl if you want the full picture.

When Should You Actually Use ACLs?

ACLs are not something you need every day, but they're the right tool when:

• Multiple users need different access levels to the same file/directory

• You're managing a shared server or development environment

• You need fine-grained control without the overhead of creating new groups for every scenario

For personal machines and simple setups, standard permissions are usually enough. ACLs shine in multi-user environments.

Next Steps

Give me a follow if you found this useful. Drop a comment with your thoughts