Mastering Linux Access Control Lists (ACLs)

Introduction

Managing file permissions with precision in enterprise environments is critical for maintaining security and compliance. Traditional Linux file permissions (rwx for user, group, others) work well in simple cases but fall short when dealing with complex permission requirements. This is where Access Control Lists (ACLs) come in, providing fine-grained control over who can access and modify files and directories.

This guide dives into advanced use cases for ACLs, illustrating how they can be leveraged in real-world scenarios to solve complex permission challenges.

Scenario 1: Granular Permission Management in a Collaborative Environment

Use Case: A shared directory /shared/projects is used by multiple teams, each requiring different levels of access to project files. The directory needs to be configured so that:

- The developers group has full access (read, write, execute) to all files.

- The qa group has read and execute access but should not modify files.

- A specific user, alice, who is not part of any group, needs write access to specific files within the directory.

Steps:

1. Installing ACL Tools

To manage ACLs, you'll need the acl package, which includes the getfacl and setfacl utilities. On Debian-based systems, you can install it using:

$ sudo apt-get install acl

On Red Hat-based systems:

$ sudo yum install acl

2. Grant full access to the developers group:

$ setfacl -R -m g:developers:rwx /shared/projects

3. Grant read and execute access to the qa group:

$ setfacl -R -m g:qa:rx /shared/projects

4. Grant write access to alice for specific files:

$ setfacl -m u:alice:rw /shared/projects/report.txt

5. Set default ACLs for new files:

To ensure all new files created within /shared/projects inherit the correct permissions:

$ setfacl -d -m g:developers:rwx /shared/projects

$ setfacl -d -m g:qa:rx /shared/projects

Verify changes:

$ getfacl /shared/projects/report.tx

# file: /shared/projects/report.txt
# owner: root
# group: root
user::rw-
user:alice:rw-  # alice has specific write access
group::r--
group:developers:rwx  # developers have full access
group:qa:rx  # qa has read and execute access
mask::rwx
other::r--        

This setup allows the developers group to fully manage the files, while qa can only read and execute, and alice has special write permissions on the report.txt file.

Scenario 2: Regulatory Compliance with Auditing Requirements

Use Case: A company must comply with regulatory standards that require strict control and logging of file access. The /finance directory contains sensitive financial records. The requirements are:

- Only the finance group can access and modify files.

- The audit group must have read-only access to review the files without modifying them.

- All access attempts must be logged for auditing purposes.

Steps:

1. Grant full access to the finance group:

$ setfacl -R -m g:finance:rwx /finance

2. Grant read-only access to the audit group:

$ setfacl -R -m g:audit:r-- /finance

3. Configure logging of ACL modifications:

Use auditd to log ACL changes. First, install and start the audit service:

$ sudo apt-get install auditd

$ sudo service auditd start

4. Set up auditing rules for /finance:

$ auditctl -w /finance -p wa -k finance_acls

- -w specifies the directory to watch.

- -p wa specifies to log write (`w`) and attribute changes (`a`).

- -k assigns a key (`finance_acls`) to this audit rule for easy searching.

Verify changes:

To view the ACLs:

$ getfacl /finance

# file: /finance
# owner: root
# group: root
user::rwx
group::r-x
group:finance:rwx # finance group has full access
group:audit:r-- # audit group has read-only access
mask::rwx
other::---        

To check audit logs:

$ ausearch -k finance_acls

This setup ensures that only authorized users can access or modify financial records while ensuring that all access attempts are logged for compliance purposes.

Scenario 3: Controlled Access in a Multi-Tenant Environment

Use Case: In a multi-tenant server environment, different clients have isolated directories under /clients. Each client should only access their own directory, but a support group must have read access to all client directories for troubleshooting purposes.

Steps:

1. Create directories for each client:

$ mkdir /clients/clientA /clients/clientB

2. Set up ACLs for each client directory:

$ setfacl -m u:clientAuser:rwx /clients/clientA

$ setfacl -m u:clientBuser:rwx /clients/clientB

3. Grant read-only access to the support group:

$ setfacl -R -m g:support:rx /clients/clientA

$ setfacl -R -m g:support:rx /clients/clientB

4. Ensure no access between clients:

This step is implicit because each client's directory has specific ACLs, ensuring isolation. However, verify with:

$ getfacl /clients/clientA /clients/clientB

Verification:

$ getfacl /clients/clientA

# file: /clients/clientA
# owner: root
# group: root
user::rwx
user:clientAuser:rwx  # clientA has full access
group::---
group:support:rx  # support has read access
mask::rwx
other::---        

This configuration ensures that each client has exclusive access to their own data while allowing support staff to perform read-only troubleshooting.

Scenario 4: Complex Permission Inheritance with Default ACLs

Use Case: In a research environment, a directory /research contains subdirectories for various projects. Each project directory should automatically inherit specific permissions when new files or directories are created. The requirements are:

- The research group should have full control over all new files.

- The public group should have read-only access to all new files.

- Specific users (e.g., jane) need write access to all new files in a particular project.

Steps:

1. Set default ACLs for the research group:

$ setfacl -d -m g:research:rwx /research

2. Set default ACLs for the public group:

$ setfacl -d -m g:public:r-- /research

3. Grant specific user jane write access to a particular project:

$ mkdir /research/projectX

$ setfacl -d -m u:jane:rw /research/projectX

Verification:

Create a new file within /research/projectX and check its permissions:

$ touch /research/projectX/newfile.txt

$ getfacl /research/projectX/newfile.txt

# file: /research/projectX/newfile.txt
# owner: root
# group: root
user::rw-
user:jane:rw-  # jane has write access by default
group::r--
group:research:rwx  # research group has full control
group:public:r--  # public group has read-only access
mask::rwx
other::---
default:user::rw-
default:user:jane:rw-
default:group::r--
default:group:research:rwx
default:group:public:r--        

This scenario ensures that newly created files and directories within the /research directory inherit the correct permissions, streamlining collaboration and maintaining security.

Thus, Linux Access Control Lists (ACLs) provide powerful tools for managing complex permission scenarios that go beyond the capabilities of traditional file permissions. Whether dealing with multi-tenant environments, compliance requirements, or collaborative projects, understanding and using ACLs effectively can significantly enhance your system's security and usability.