Linux in Action: Mastering ACLs (Access Control Lists) for RHCSA

Introduction

Basic Unix permissions (rwx) work well for many scenarios—but they can fall short when we need fine‑grained access control. Access Control Lists (ACLs) extend the traditional model, allowing you to grant specific permissions to additional users or groups without altering the file’s primary ownership.

ACL management is a core skill assessed in the Red Hat Certified System Administrator (RHCSA) exam and is vital for real‑world multi‑tenant environments.

📌 This guide focuses on the exact depth of ACL knowledge required for RHCSA, with practical demonstrations you can reproduce in a lab.

Table of Contents

• What Are ACLs and Why Use Them?
• Viewing Current ACLs with getfacl
• Granting Permissions with setfacl -m
• Default ACLs for Directories
• Removing ACL Entries
• Best Practices and Exam Tips
• Real-World Use Case
• Conclusion

What Are ACLs and Why Use Them? and Why Use Them?

Traditional permissions map a single owner, group, and others to rwx bits. ACLs let you assign additional rules such as “give user bob read access to /shared/logs/” without changing group ownership.

Key benefits:

• Fine‑tuned collaboration between teams
• Avoids creating numerous ad‑hoc groups
• Granular permissions for backup, audit, or DevOps service accounts

RHCSA Scope: You must know how to view, add, modify, and delete ACLs and set default ACLs on directories.

Viewing Current ACLs with getfacl

# getfacl /srv/projects/

Sample output:

# file: srv/projects/
# owner: root
# group: devops
drwxrwx---+
user::rwx
group::rwx
other::---
user:alice:r-x

• + after directory permissions indicates extended ACLs exist.
• Extra line user:alice:r-x shows ACL entry for user alice.

Granting Permissions with setfacl -m

Give a user access

# setfacl -m u:alice:rwx /srv/projects/

-m modifies or adds an entry. Always use rwx letters (RHCSA recommendation) rather than octal.

Give a group access

# setfacl -m g:qa:r-x /srv/projects/

Verify:

# getfacl /srv/projects/

Default ACLs for Directories

A default ACL applies automatically to new files/directories created inside the parent directory.

# setfacl -d -m u:alice:rwx /srv/projects/

• -d targets default ACL.
• Combine with regular ACLs for full control.

🔎 RHCSA Tip: The exam often asks you to ensure future files inherit a permission—this is where default ACLs shine.

Removing ACL Entries

Remove a single ACL rule

# setfacl -x u:alice /srv/projects/

Strip all ACLs (restore basic permissions)

# setfacl -b /srv/projects/

Re‑check with getfacl to confirm cleanup.

Best Practices and Exam Tips

Exam strategy

• Always run getfacl before and after changes to verify.
• Use rwx syntax over numeric.
• Remember default ACLs affect newly created items, not existing ones.

Real-World Use Case

Scenario: Secure Collaboration in a FinTech DevOps Pipeline

A FinTech company hosts its application code under /srv/app-repos/. Development and operations teams need different levels of access:

Default ACL ensures any future sub‑directories inherit these rules:

setfacl -d -m g:devs:rx /srv/app-repos/
setfacl -d -m g:sre:rwx /srv/app-repos/

Business impact:

• Developers cannot accidentally modify production artifacts.
• CI/CD automation writes builds securely without broadening group ownership.
• SREs maintain rapid incident response capability.
• Meets PCI-DSS separation‑of‑duties requirements without complex group sprawl.

Conclusion

ACLs provide the missing granularity when basic permissions aren’t enough. For RHCSA success—and real‑world DevOps security—you must be comfortable viewing, setting, and removing ACLs on both files and directories.

🔜 Next Article Preview: We’ll dive into Special Permissions—SetUID, SetGID, and the Sticky Bit—to complete the permissions trilogy for your RHCSA prep.

Connect with me on LinkedIn for further discussions and networking opportunities.