Advanced Permissions (ACLs): Granular Security for Linux

Previously in this course, we covered File Permissions Fundamentals and Modifying Permissions with Chmod. While standard permissions (owner, group, others) handle most scenarios, they often fall short when you need to grant specific access to multiple users or groups without creating complex, messy group structures.

This is where Access Control Lists (ACLs) come in. They allow you to define fine-grained permissions for files and directories, letting you assign specific read, write, or execute rights to individual users or groups beyond the standard triplet.

Understanding ACLs from First Principles

Standard Linux permissions are limited: you only have one owner, one group, and "everyone else." If you have a web server project directory where user1 needs read access, user2 needs write access, and group-developers needs read-execute, standard permissions cannot represent this natively.

ACLs extend this model by adding an extra "mask" and a list of specific user/group entries to the inode of the file. When a process attempts to access a file, the kernel checks the standard permissions first. If they don't apply, it traverses the ACL entries to see if the user is explicitly granted permission.

Viewing ACLs with getfacl

Before we modify anything, let's see how to inspect these permissions. You likely already have the acl package installed (it's standard on most distros).

To view the ACL settings for a file or directory, use the getfacl command:

Bash
getfacl /var/www/my-project/logs/app.log

If you see a standard output showing only owner, group, and other, it means no specific ACLs have been set yet. Once you apply custom rules, getfacl will display an extended list of entries.

Managing Permissions with setfacl

The setfacl command is your primary tool for adding, modifying, or removing these granular permissions. We’ll apply this to our ongoing project, where we want to give a specific user (audit-bot) read-only access to our server logs without giving them ownership.

Worked Example: Granting Read Access

Suppose we have a log file at /var/www/my-project/logs/access.log. We want the user audit-bot to be able to read it, but nothing more.

1. Grant read access to a specific user: The -m (modify) flag is used to change the ACL entries.

   Bash
   sudo setfacl -m u:audit-bot:r /var/www/my-project/logs/access.log
   

2. Verify the change: Run getfacl again. You will notice a new line starting with user:audit-bot:r--.

3. Granting directory access: If you want to grant access to a whole directory, use the -R (recursive) flag:

   Bash
   sudo setfacl -R -m u:audit-bot:rx /var/www/my-project/logs/
   

   Note: Using rx allows the user to both see the files in the directory and read them.

Removing ACLs

If you make a mistake or no longer need the granular access, you can remove a specific entry using the -x flag:

Bash
sudo setfacl -x u:audit-bot /var/www/my-project/logs/access.log

To strip all ACLs from a file and return it to default standard permissions, use the -b (remove all) flag:

Bash
sudo setfacl -b /var/www/my-project/logs/access.log

Hands-on Exercise

For this exercise, return to your project directory.

1. Create a dummy test file in your project logs folder if it doesn't exist.
2. Use getfacl to see the current state.
3. Use setfacl to grant your own standard user account (or a secondary user if you have one) write access to that specific file.
4. Verify the change with getfacl and confirm you can append text to the file using >>.
5. Remove the ACL entry and confirm your access is revoked.

Common Pitfalls

• Ignoring the Mask: When you set an ACL, Linux creates a "mask" that limits the maximum permissions any named user or group can have. If you manually run chmod on a file with ACLs, it may change the mask, effectively "silencing" your ACL entries. Always check your ACLs after running a bulk chmod.
• Recursive Complexity: Be careful when using setfacl -R. It applies permissions to everything. If you set rwx on a directory recursively, you might accidentally make sensitive configuration files executable or writable by users who shouldn't have that level of access.
• Filesystem Support: While rare on modern systems, ACLs require the underlying filesystem to support them. If you get a "not supported" error, check if your partition was mounted with acl support in /etc/fstab.

FAQ

Q: Are ACLs better than standard groups? A: They are more flexible but harder to audit at a glance. Standard groups are preferred for most workflows; use ACLs only when you need "exceptions" to the rule.

Q: Does ls -l show ACLs? A: Yes, if a file has an ACL, the permissions string in ls -l will end with a + symbol (e.g., -rw-r--r--+).

Q: Can I use ACLs on directories to set default permissions for new files? A: Yes, using the -d flag with setfacl (default ACLs) ensures that any new files created within that directory inherit the specified ACL rules.

Recap

We have moved beyond basic permissions by implementing granular access control. You now have the tools to:

• Inspect existing permissions using getfacl.
• Grant specific user/group access using setfacl -m.
• Remove specific or all ACL entries to maintain security hygiene.

These skills are essential when hardening your server against unauthorized access while maintaining the flexibility required for developer and service-user workflows.

Up next: We will begin exploring how to manage and secure remote connections to your server using advanced SSH configurations.