File Protection - Learning Module

Loading content...

0/227

Access Control Lists: Fine-Grained File Permissions

Beyond the Three Classes

The User/Group/World model works beautifully for simple scenarios. But modern computing demands more flexibility. Consider a collaborative project where:

Alice needs read/write access
Bob needs read-only access
Carol needs execute access
The 'developer' group needs read access
The 'auditor' group needs read access, but only to metadata

With only three permission classes and one group per file, this is impossible. Access Control Lists (ACLs) solve this by attaching arbitrary permission entries to files, allowing per-user and per-group specifications without the administrative overhead of creating groups for every permission combination.

What You Will Learn

By the end of this page, you will understand: how ACLs extend traditional Unix permissions, POSIX ACL structure and semantics, how to read, set, and manage ACLs using getfacl and setfacl, the ACL mask mechanism and its purpose, default ACLs for new file creation, and how ACLs interact with standard permission commands like chmod.

What Are Access Control Lists?

An Access Control List is a list of permissions attached to a file system object, specifying which users or groups have which access rights. Unlike the fixed three-class Unix model, ACLs can contain an arbitrary number of entries.

Conceptual model:

Think of an ACL as implementing the column of an access control matrix (covered in Page 1). For a single file, the ACL stores:

Permission entries for specific named users
Permission entries for specific named groups
The standard owner, owning group, and other entries
A mask that limits effective permissions for named users and groups

Comparison: Traditional Permissions vs ACLs
Feature	Traditional Unix	POSIX ACLs
Permission entries	Exactly 3 (owner, group, other)	Unlimited named users/groups
Groups per file	Exactly 1	Multiple via ACL entries
Granularity	Class-based	User-specific and group-specific
Storage	In inode (9 bits + 3 special)	Extended attributes (additional metadata)
Compatibility	Universal	Requires filesystem and tool support
Complexity	Simple to audit mentally	Requires tools (getfacl) to fully view
Default for new files	umask-derived	Can inherit from parent directory ACL

Two types of ACLs:

Access ACLs — Applied directly to files and directories. Control access to that specific object.
Default ACLs — Apply only to directories. Specify ACL entries that new files and subdirectories inherit. This enables permission inheritance without setgid.

POSIX ACLs (IEEE 1003.1e/2c) are the standard on Linux and most Unix systems. Windows uses NTFS ACLs, which are more complex and support different semantics.

POSIX ACLs Never Became Official

The POSIX ACL draft (1003.1e) was withdrawn before final standardization due to lack of consensus. However, the draft was widely implemented and is now the de facto standard on Linux (via libacl), FreeBSD, Solaris, and macOS. The specification is stable despite never being officially ratified.

ACL Entry Types

A POSIX ACL consists of multiple entries, each specifying permissions for a specific qualifier (user, group, or category). There are six entry types:

POSIX ACL Entry Types
Entry Type	Syntax	Description	Required?
user::perms	`user::rwx`	File owner permissions (like traditional owner)	Yes
user:name:perms	`user:bob:r-x`	Named user permissions (specific user)	No
group::perms	`group::r-x`	Owning group permissions (like traditional group)	Yes
group:name:perms	`group:dev:rw-`	Named group permissions (specific group)	No
mask::perms	`mask::r-x`	Maximum effective perms for named users/groups	If named entries exist
other::perms	`other::r--`	Permissions for everyone else	Yes

The minimal ACL:

Every file has at least three ACL entries: user::, group::, and other::. These exactly correspond to the traditional Unix permission bits. A file with only these three entries has a minimal ACL and behaves identically to the traditional model.

Extended ACLs:

When named user or named group entries are added, the ACL becomes an extended ACL. Extended ACLs require a mask entry and have more complex evaluation rules.

How you know a file has an ACL:

acl_indicator.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
# Files with extended ACLs show '+' in ls output
$ ls -l
-rw-r--r--  1 alice alice  1024 Jan 16 10:00 normal.txt
-rw-r--r--+ 1 alice alice  2048 Jan 16 10:00 with_acl.txt
          ^
          └── The '+' indicates an extended ACL exists
 
# View full ACL with getfacl
$ getfacl with_acl.txt
# file: with_acl.txt
# owner: alice
# group: alice
user::rw-              # File owner (alice)
user:bob:r--           # Named user entry (bob)
group::r--             # Owning group
group:developers:rw-   # Named group entry
mask::rw-              # Effective rights mask
other::---             # Everyone else

Named Entry Format

Named entries use the format type:qualifier:permissions. The qualifier is the username or groupname. For example: user:bob:r-x grants bob read and execute. group:interns:r-- grants the interns group read-only. Without a qualifier (just user::), it refers to the owner/owning group.

The ACL Mask: Limiting Effective Permissions

The mask entry is the most misunderstood aspect of POSIX ACLs. It defines the maximum effective permissions for all named user entries, named group entries, AND the owning group entry.

The formula:

Effective Permissions = Granted Permissions AND Mask

Only the owner (user::) and other (other::) entries are NOT affected by the mask. Everything else is filtered through it.

mask_demo.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
# Demonstrating mask behavior
 
$ getfacl restricted.txt
# file: restricted.txt
# owner: alice
# group: alice
user::rw-                # Alice (owner): rw- (NOT masked)
user:bob:rw-             # Bob: rw- in ACL...
group::rw-               # Owning group: rw- in ACL...
group:developers:rwx     # Developers: rwx in ACL...
mask::r--                # BUT mask is read-only!
other::---               # Others: no access (NOT masked)
 
# Effective permissions (what actually applies):
# - alice: rw- (owner bypasses mask)
# - bob: rw- AND r-- = r-- (masked to read-only)
# - owning group: rw- AND r-- = r-- (masked)
# - developers: rwx AND r-- = r-- (masked, even execute removed!)
# - others: --- (not masked, but already no access)
 
# getfacl shows effective permissions when mask applies:
$ getfacl restricted.txt
user:bob:rw-             #effective:r--
group::rw-               #effective:r--
group:developers:rwx     #effective:r--
 
# The #effective: comment shows what actually applies!

Why does the mask exist?

The mask solves a critical compatibility problem:

Traditional tools (like chmod) only understand 9 permission bits
When you use chmod g-w file, the system can't know about named entries
The mask maps to the traditional group permission bits
Changing group permissions via chmod actually changes the mask!

The mask-group synchronization:

mask_chmod.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# chmod interacts with the mask, not the group entry
 
$ getfacl myfile.txt
user::rw-
user:bob:rw-
group::rw-
mask::rw-
other::r--
 
# Traditional group bits show: rw-r--r-- (group is rw-)
$ ls -l myfile.txt
-rw-rw-r--+ 1 alice alice 1024 Jan 16 10:00 myfile.txt
 
# Now remove group write with chmod
$ chmod g-w myfile.txt
$ ls -l myfile.txt
-rw-r--r--+ 1 alice alice 1024 Jan 16 10:00 myfile.txt
 
# What actually changed? The MASK!
$ getfacl myfile.txt
user::rw-
user:bob:rw-             #effective:r--  ← Bob lost write!
group::rw-                              ← Still says rw-!
mask::r--                               ← Mask changed!
other::r--
 
# The group:: entry still has write, but mask filters it out.
# This is how chmod stays compatible with ACLs.

chmod Can Accidentally Restrict ACL Permissions

If you have named user entries granting write access, and someone runs chmod 644 file, the mask becomes r-- and all named users lose write access! Their ACL entries still exist, but the mask limits them. Always use getfacl to check effective permissions after chmod on ACL-enabled files.

Managing ACLs with setfacl

The setfacl command modifies ACLs. Unlike chmod, it can add, modify, or remove individual ACL entries.

setfacl_examples.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
# =====================================================
# Adding ACL Entries (-m / --modify)
# =====================================================
 
# Grant user bob read permission
setfacl -m u:bob:r myfile.txt
 
# Grant user carol read/write permission
setfacl -m u:carol:rw myfile.txt
 
# Grant group developers read/execute permission
setfacl -m g:developers:rx myfile.txt
 
# Multiple entries at once (comma-separated)
setfacl -m u:alice:rw,u:bob:r,g:staff:r myfile.txt
 
# =====================================================
# Modifying Existing Entries
# =====================================================
 
# Same syntax - if entry exists, it's updated
setfacl -m u:bob:rw myfile.txt  # Change bob from r to rw
 
# Set the mask explicitly (affects all named entries)
setfacl -m m::rx myfile.txt
 
# =====================================================
# Removing ACL Entries (-x / --remove)
# =====================================================
 
# Remove bob's ACL entry
setfacl -x u:bob myfile.txt
 
# Remove developers group entry
setfacl -x g:developers myfile.txt
 
# Note: you cannot remove owner/group/other/mask entries
# Those are structural - use chmod to modify them
 
# =====================================================
# Removing All Extended ACLs (-b / --remove-all)
# =====================================================
 
# Restore to minimal ACL (just owner/group/other)
setfacl -b myfile.txt
 
# After -b, the '+' disappears from ls -l
 
# =====================================================
# Recursive Operations (-R)
# =====================================================
 
# Apply ACL to directory and all contents
setfacl -R -m u:bob:r project/
 
# Remove specific entry recursively
setfacl -R -x u:bob project/
 
# =====================================================
# Copying ACLs (--copy-from)
# =====================================================
 
# Copy ACL from one file to another
getfacl source.txt | setfacl --set-file=- dest.txt
 
# =====================================================
# Common Patterns
# =====================================================
 
# Make file readable by specific user only (plus owner)
chmod 600 secret.txt
setfacl -m u:auditor:r secret.txt
 
# Collaborative file: owner full, group write, specific user read
setfacl -m g:team:rw,u:contractor:r project.doc
 
# Verify the result
getfacl secret.txt

Permission Specifications

Permissions can be specified as: rwx (letters), 7 (octal digit), or --- (explicit none). You can also use - for denied bits: r-x means read and execute, no write. The format is flexible: u:bob:r, user:bob:r, user:bob:4 all mean the same thing.

Default ACLs: Inheritance for New Files

Default ACLs apply only to directories and control what ACL entries new files and subdirectories inherit. They solve the problem of ensuring consistent permissions in shared directories without requiring manual setup for each new file.

How default ACLs work:

A directory can have both an access ACL (for the directory itself) and a default ACL (for new entries)
When a file is created inside, the default ACL becomes its access ACL (modified by umask)
When a subdirectory is created, it inherits both the default ACL as access AND as its own default
Default ACLs propagate infinitely down the tree

default_acl.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
# =====================================================
# Setting Default ACLs (-d flag or d: prefix)
# =====================================================
 
# Set default ACL: all files created here will be readable by bob
setfacl -d -m u:bob:r shared_project/
 
# Alternative syntax with d: prefix
setfacl -m d:u:bob:r shared_project/
 
# Set multiple default entries
setfacl -d -m u::rwx,g::rx,o::---,u:bob:r,g:developers:rw shared_project/
 
# =====================================================
# Viewing Default ACLs
# =====================================================
 
$ getfacl shared_project/
# file: shared_project/
# owner: alice
# group: alice
user::rwx
group::r-x
other::---
 
# Default entries (apply to new files/dirs):
default:user::rwx
default:user:bob:r--
default:group::r-x
default:group:developers:rw-
default:mask::rwx
default:other::---
 
# =====================================================
# Demonstrating Inheritance
# =====================================================
 
# Create a file in the directory
$ touch shared_project/newfile.txt
$ getfacl shared_project/newfile.txt
# file: shared_project/newfile.txt
# owner: alice
# group: alice
user::rw-            # From default:user:: (minus execute - it's a file)
user:bob:r--         # Inherited from d:u:bob:r
group::r-x           # From default:group::
group:developers:rw- # Inherited from d:g:developers:rw
mask::rw-            # Computed from inherited entries
other::---           # From default:other::
 
# Create a subdirectory
$ mkdir shared_project/subdir
$ getfacl shared_project/subdir/
# Inherits BOTH access ACL AND default ACL
default:user::rwx
default:user:bob:r--
default:group::r-x
default:group:developers:rw-
default:mask::rwx
default:other::---
 
# =====================================================
# Removing Default ACLs
# =====================================================
 
# Remove all default ACL entries
setfacl -k shared_project/
 
# Remove specific default entry
setfacl -x d:u:bob shared_project/

Default ACLs vs setgid

•setgid: New files inherit group only
•Default ACL: New files inherit full ACL
•setgid: Single group propagation
•Default ACL: Multiple users/groups
•setgid: Simpler, widely understood
•Default ACL: More flexible, less known

When to Use Default ACLs

•Shared project directories
•Multiple groups need consistent access
•Specific users need special permissions
•Contractor/auditor access patterns
•Complex permission inheritance needed
•Can't modify system group memberships

umask Still Applies to Inherited ACLs

When a file inherits a default ACL, the creating process's umask is still applied to the inherited permissions. If your default ACL grants rw- but umask is 0077, new files get --- for non-owner entries. Set umask appropriately or use restrictive defaults.

How the Kernel Evaluates ACLs

When a process requests access to a file with an ACL, the kernel evaluates entries in a specific order. Understanding this order is critical for predicting access outcomes.

acl_evaluation.txt

ACL Evaluation

ACL Permission Evaluation Algorithm:
 
1. If process effective UID == file owner UID:
   → Use user:: entry
   → DONE (owner never uses mask)
 
2. If there's a user:username: entry matching process UID:
   → Use that entry's permissions AND mask
   → DONE
 
3. If process has a group matching any group:groupname: entry:
   → Collect permissions from ALL matching group entries
   → UNION the permissions (most permissive wins)
   → Apply mask to the union
   → DONE
 
4. If process has a group matching file's owning group:
   → Use group:: entry AND mask
   → DONE
 
5. Otherwise:
   → Use other:: entry
   → DONE (other never uses mask)
 
Key Points:
┌─────────────────────────────────────────────────────────────┐
│ • Owner always uses user:: entry (never masked)             │
│ • Named users are checked BEFORE group memberships          │
│ • If a named user matches, groups are NOT checked           │
│ • Multiple matching group entries: permissions UNION        │
│ • Owner and Other: NOT subject to mask                      │
│ • Everything else: subject to mask                          │
└─────────────────────────────────────────────────────────────┘

Example: Multiple group matches:

multi_group.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
# Carol is in groups: staff, developers, marketing
 
$ getfacl project.txt
user::rw-
group::r--              # Owning group (not 'staff')
group:staff:r--
group:developers:rw-
group:marketing:--x     # Unusual but legal
mask::rwx
other::---
 
# Carol's access calculation:
# 1. Is carol the owner? No
# 2. Is there a user:carol: entry? No
# 3. Is carol in any named groups? Yes! All three!
#    - staff: r--
#    - developers: rw-
#    - marketing: --x
#    Union: rwx (all bits that ANY group grants)
#    Apply mask (rwx): rwx AND rwx = rwx
# 4. (Skip - used named groups)
# 5. (Skip - not other)
 
# Result: Carol has rwx access!
 
# Important implication:
# If you want to DENY a specific group, you can't just give them
# fewer permissions - they might get access through another group.
# ACLs don't support DENY entries in POSIX model.

POSIX ACLs Have No DENY Entries

Unlike Windows NTFS ACLs, POSIX ACLs can only grant permissions, not explicitly deny them. If a user is in multiple groups, they get the UNION of all matching group permissions. To deny access, you must ensure no matching entry grants access—sometimes requiring removal from groups or using other:: restrictions.

Filesystem and Tool Support

ACLs require support at multiple levels: the filesystem, the kernel, and userspace tools. Not all environments fully support ACLs, and this can cause problems when files are transferred.

Filesystem ACL Support
Filesystem	ACL Support	Notes
ext4	Full POSIX ACL	Default on most Linux; mount option may be needed on older systems
XFS	Full POSIX ACL	Enabled by default
Btrfs	Full POSIX ACL	Enabled by default
ZFS (Linux)	Full POSIX ACL	Also supports NFSv4-style ACLs
NTFS (via ntfs-3g)	Emulated	Maps NTFS ACLs to POSIX where possible
FAT32/exFAT	None	No ACL support; permissions are fake
NFS	Depends on version	NFSv4 has native ACL support; v3 requires extensions
CIFS/SMB	Translated	Windows ACLs mapped to POSIX; imperfect translation

Enabling ACLs:

On modern Linux with ext4, ACLs are typically enabled by default. If not:

enable_acl.sh
Shell
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# Check if ACLs are enabled (look for 'acl' in mount options)
$ mount | grep /dev/sda1
/dev/sda1 on / type ext4 (rw,relatime,acl)
 
# Enable ACLs at mount time
sudo mount -o remount,acl /
 
# Or add to /etc/fstab for persistence
# /dev/sda1  /  ext4  defaults,acl  0  1
 
# Verify ACL support by setting one
$ touch testfile
$ setfacl -m u:nobody:r testfile
$ getfacl testfile
# If this works without errors, ACLs are supported

ACL Preservation in File Operations

When copying or archiving files, ACLs can be lost!

cp preserves ACLs only with -a or --preserve=all
tar needs --acls flag to include ACLs in archive
rsync needs -A or --acls flag
Standard tools may silently drop ACLs without warning

Always verify ACLs are preserved in your backup and deployment procedures.

ACL Implementation Best Practices

ACLs provide powerful flexibility, but can also create complex, hard-to-audit permission structures. Follow these practices for maintainable systems:

ACL Best Practices

•Prefer groups over named users — Instead of u:bob:rw,u:carol:rw,u:dave:rw, add all three to a group and use g:team:rw. Easier to manage when team composition changes.
•Document ACL purposes — Keep a README or comment explaining why each ACL entry exists. ACLs are invisible to ls; future admins won't know why they're there.
•Use default ACLs for directories — Instead of applying ACLs to every existing and future file, set defaults on the directory and let inheritance work.
•Be cautious with mask changes — Remember that chmod modifies the mask on ACL-enabled files. This can inadvertently revoke named user/group access.
•Audit regularly — Use getfacl -R directory to dump ACLs recursively. Review for stale entries (former employees, old contractors, obsolete groups).
•Test ACL-unaware tools — Before deploying backups created with cp/tar/rsync, verify they actually preserved ACLs.
•Minimize complexity — ACLs are powerful, but a simple permission structure is easier to secure. Don't use ACLs when traditional permissions suffice.
•Set conservative other:: permissions — Since ACLs only grant, never deny, ensure other:: doesn't inadvertently provide access. Use other::--- for sensitive directories.

Scripting ACL Deployment

For reproducible permission setups, script your ACL configuration:

#!/bin/bash
setfacl -R -b /project  # Remove all ACLs first
setfacl -R -m g:developers:rwx /project
setfacl -R -d -m g:developers:rwx /project
setfacl -m u:auditor:rx /project/reports

Version control this script alongside your infrastructure-as-code.

Summary: Access Control Lists

Key Takeaways

•ACLs extend Unix permissions — Adding named user and group entries beyond the owner/group/other triad.
•Six entry types — user::, user:name:, group::, group:name:, mask::, other:: — covering all access specification needs.
•The mask limits effective permissions — All named entries and group:: are filtered through the mask. Owner and other bypass it.
•chmod modifies the mask — On files with extended ACLs, group permission changes actually change the mask, affecting all named entries.
•Default ACLs enable inheritance — New files in a directory with default ACL entries inherit those entries automatically.
•Evaluation follows strict order — Owner → named user → union of matching groups → owning group → other. First match wins (except group union).
•No DENY entries in POSIX — ACLs can only grant; deny must be achieved through absence of grant.
•Filesystem support required — ACLs need both kernel and filesystem support; preservation requires tool-specific flags.

What's next:

The next page explores Capabilities—an entirely different approach to access control where permission to access objects is represented as unforgeable tokens held by the subject, rather than policies stored with the object. This model underpins file descriptors, some modern security frameworks, and several experimental operating systems.

Page Complete

You now understand POSIX ACLs in depth—their structure, the crucial mask mechanism, how to set and manage them, default ACL inheritance, and evaluation semantics. This knowledge enables fine-grained access control that overcomes the limitations of basic Unix permissions.