Linux ACL: How to Set ‘Ultra-Detailed’ Permissions for Each User (Replacing chmod 777)

Linux tutorial - IT technology blog
Linux tutorial - IT technology blog

When traditional chmod is no longer enough

2 AM. My phone vibrates incessantly with 15 missed calls. On the other end, the Lead Dev panics: “Bro, the source code folder is a mess. The new Dev can’t edit files, but if I chmod 777 it, Marketing will see the .env file containing database passwords. Save me!”

This is a scenario sysadmins encounter all too often. Linux’s traditional permissions (Owner – Group – Others) are powerful but lack flexibility for safe permission management. You only have one group to assign permissions. But reality is different: User A needs read/write, User B needs read-only, the QC Group needs to see logs but absolutely cannot delete them, and strangers shouldn’t see anything.

When I first started, I struggled for hours with chown and chgrp only to hit a dead end. That’s when I realized: to be a professional, you must use Access Control Lists (ACL).

Think of chmod as a general admission ticket, while ACL is a VIP guest list. Whoever is on the list gets in, and everyone has their own specific permissions without stepping on each other’s toes. You no longer need to create dozens of nested groups just for temporary access needs.

Checking your ‘weapons’ before the battle

Most modern distros (Ubuntu 22.04+, CentOS 8+, AlmaLinux) have ACL enabled by default. However, don’t be complacent. Spend 10 seconds checking to avoid the ‘Command not found’ error.

Install the acl tool package with a single command:

# For Ubuntu/Debian
sudo apt update && sudo apt install acl -y

# For RHEL/CentOS/AlmaLinux
sudo dnf install acl -y

A small tip: Use mount | grep -i acl to make sure the disk partition supports this option. With modern filesystems like EXT4 or XFS, ACL is usually built into the kernel, so you’re good to go.

Configuring ACL: ‘Life-saving’ commands

Back to the /data/project_X folder with the permission error. We’ll use two main tools: getfacl (to inspect) and setfacl (to apply permissions).

Granting permissions to individuals

Suppose tuan_anh needs to edit config.php. Normally, you’d have to change the file’s Owner to tuan_anh, but that would break the execution rights of www-data (the Web server). With ACL, it’s much cleaner:

# Grant read and write (rw-) permissions specifically to user tuan_anh
sudo setfacl -m u:tuan_anh:rw /data/project_X/config.php

Here, -m stands for modify, and u:tuan_anh:rw means: The user named tuan_anh has read/write permissions. Done! The file still belongs to root, the Web server still runs, and tuan_anh works perfectly fine.

Granting permissions to a specific Group

For example, the Marketing team (group mkt_team) wants to view documents in /data/docs for content creation. They only need read access, no editing or deleting:

sudo setfacl -m g:mkt_team:r /data/docs

This command keeps your system clean, avoiding the headache of creating nested groups.

Default ACL: The ‘set once, use forever’ secret

This is my favorite part. Normally, when tuan_anh creates a new file, other members won’t have permission to view it. To solve this once and for all, we use Default ACL:

# Future sub-files/folders will automatically have permissions for dev_team
sudo setfacl -d -m g:dev_team:rwx /data/project_X

The -d (default) option ensures every new file created in project_X automatically inherits the permissions of the dev_team group. You’ll no longer receive those Monday morning complaints about access permissions.

Monitoring: Don’t let the “+” sign fool you

After running the commands, if you use ls -l, look closely at the end of the permission string:

-rw-rw-r--+ 1 root root 1024 Apr 24 02:15 config.php

See that tiny + sign? It indicates this file is using ACL. Don’t fully trust what ls -l shows now because it might not reflect the actual permissions. Use getfacl to see the full picture:

getfacl /data/project_X/config.php

The result will clearly list who has what rights. Pay special attention to the mask line. This is the maximum permission (ceiling) allowed by ACL. If you set the mask to r--, even if you grant a user rwx, they will effectively only be able to read the file. This is the final security check to prevent over-provisioning.

If you want to wipe the ACL and start fresh, use:

# Wipe all ACLs, returning the file to pure Linux permissions
sudo setfacl -b /data/project_X/config.php

Conclusion

ACL isn’t rocket science, but it’s the boundary between an amateur sysadmin and a professional systems administrator who utilizes fine-grained permissions. Instead of struggling with risky chmod 777 commands, take 5 minutes to set up ACLs. It makes the system more secure and, most importantly, helps you sleep better at night.

Share: