Operating SystemsAccess Control Lists

Access Control Lists

LevelIntermediate

Duration90 mins

TopicAccess Control Lists

2 / 5

ACL Entries

The Building Blocks of Access Control

If an Access Control List is a complete sentence describing who can do what to an object, then Access Control Entries (ACEs) are the individual words that compose that sentence. Each ACE is a precise specification: a subject identifier, a set of permissions, and a determination of whether those permissions are granted or denied.

Mastering ACE construction is essential for implementing effective access control. A poorly constructed ACE can grant unintended access (a security vulnerability) or deny legitimate access (a usability failure). This page provides deep, practical knowledge of ACE anatomy across both POSIX and Windows systems, enabling you to craft precise, effective access control policies.

What You Will Learn

By the end of this page, you will understand the complete anatomy of ACL entries, including subject identifiers, permission bitmasks, entry types (allow/deny), and flags. You'll be able to read, write, and debug ACE specifications in both POSIX and Windows formats, and understand how different entry types interact during access evaluation.

Anatomy of an Access Control Entry

Every Access Control Entry, regardless of operating system, contains the same conceptual components. Understanding this universal structure enables you to work effectively across platforms.

Universal ACE Structure:

┌─────────────────────────────────────────────────────────────────┐
│                    Access Control Entry (ACE)                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │  Entry Type  │  │   Subject    │  │   Permission Mask    │  │
│  │              │  │  Identifier  │  │                      │  │
│  │  - Allow     │  │              │  │  - Read              │  │
│  │  - Deny      │  │  - User ID   │  │  - Write             │  │
│  │  - Audit     │  │  - Group ID  │  │  - Execute           │  │
│  │              │  │  - SID       │  │  - Delete            │  │
│  │              │  │              │  │  - etc.              │  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                          Flags                              │ │
│  │  - Inheritance (container, object, inherit-only)           │ │
│  │  - Inheritance propagation controls                        │ │
│  │  - Audit success/failure selection                         │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Core ACE Components

•Entry Type (Tag): Specifies whether this entry allows or denies access (or triggers an audit). In POSIX, the tag also identifies whether this is a named user, named group, or a special entry type like mask.
•Subject Identifier: Who this entry applies to. In POSIX, this is a UID or GID. In Windows, this is a Security Identifier (SID). Special identifiers exist for groups like 'Everyone' or 'Authenticated Users'.
•Permission Mask (Access Mask): A bitmask specifying which operations are affected by this entry. Each bit represents a specific permission like read, write, execute, delete, or change_permissions.
•Flags (optional): Additional control bits that modify how the entry is interpreted, particularly regarding inheritance and auditing.

Platform Terminology

POSIX and Windows use different terminology for the same concepts. POSIX calls entries 'ACL entries' with a 'tag' type, while Windows uses 'ACE' (Access Control Entry) with an 'ACE type'. The underlying concepts are identical—a specification of subject, permissions, and allow/deny determination.

POSIX ACL Entry Types

POSIX.1e (the draft standard implemented by Linux, FreeBSD, and other Unix systems) defines six entry types for access ACLs. Understanding each type and its role is essential for constructing correct ACLs.

The Six POSIX ACL Entry Types:

POSIX ACL Entry Types (Access ACL)
Tag Type	Qualifier	Description	Traditional Mapping
ACL_USER_OBJ	None (implied owner)	Permissions for the file owner	Owner bits (rwx------) of mode
ACL_USER	UID of named user	Permissions for a specific user by UID	No traditional equivalent
ACL_GROUP_OBJ	None (implied group)	Permissions for the owning group	Group bits (---rwx---) of mode
ACL_GROUP	GID of named group	Permissions for a specific group by GID	No traditional equivalent
ACL_MASK	None	Maximum permissions for named users and groups	Intersects with group bits in mode
ACL_OTHER	None	Permissions for everyone else	Other bits (------rwx) of mode

POSIX ACL Entry Examples
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
# View and understand each entry type
$ getfacl /project/document.txt
# file: project/document.txt
# owner: alice
# group: engineering
 
user::rw-               # ACL_USER_OBJ: alice (owner) has read+write
user:bob:r--            # ACL_USER: bob specifically has read-only
user:charlie:rw-        # ACL_USER: charlie has read+write
group::r--              # ACL_GROUP_OBJ: engineering group has read
group:marketing:r--     # ACL_GROUP: marketing group has read
group:executives:rw-    # ACL_GROUP: executives group has read+write
mask::rw-               # ACL_MASK: maximum for named users/groups is rw
other::---              # ACL_OTHER: everyone else has no access
 
# Internal representation (struct acl_entry):
struct acl_entry {
    acl_tag_t   e_tag;    /* ACL_USER_OBJ, ACL_USER, etc. */
    acl_perm_t  e_perm;   /* Permission bits (r=4, w=2, x=1) */
    id_t        e_id;     /* UID or GID (undefined for _OBJ types) */
};
 
# Binary representation in extended attribute:
# Each entry = 8 bytes: tag(2) + perm(2) + id(4)
# 
# Example for user:bob:r--
#   tag:  0x0001 (ACL_USER)
#   perm: 0x0004 (read only)
#   id:   0x000003E8 (UID 1000, typical first user)

The Critical Role of ACL_MASK:

The mask entry is often misunderstood but is crucial for POSIX ACL semantics. It sets an upper bound on permissions for named user entries, named group entries, and the owning group entry. The mask does NOT affect the owner (USER_OBJ) or others (OTHER).

Understanding the Mask Entry
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
# Scenario: We want bob to have read+write, but temporarily restrict all 
# extended permissions to read-only
 
# Initial ACL
$ getfacl file.txt
user::rw-
user:bob:rw-
group::r--
mask::rw-
other::---
 
# Effective permissions: bob has rw- (his entry AND mask = rw-)
 
# Now reduce the mask to read-only
$ setfacl -m m::r-- file.txt
$ getfacl file.txt
user::rw-               # NOT affected by mask (still rw-)
user:bob:rw-            #effective:r--
group::r--              #effective:r--
mask::r--               # Mask is now read-only
other::---              # NOT affected by mask
 
# Bob's STORED permissions are still rw-, but his EFFECTIVE permissions
# are r-- because: stored_perms & mask = rw- & r-- = r--
 
# The #effective: comment shows actual permissions after mask application
 
# This is powerful for temporary restrictions:
# - Set mask to r-- during maintenance: everyone gets read-only
# - Restore mask to rwx after: original permissions are restored
# - No need to modify individual entries!
 
# chmod on a file with ACL updates the mask, not just group bits:
$ chmod g=rx file.txt    # This sets the MASK to r-x, not the group!
$ getfacl file.txt
user::rw-
user:bob:rw-            #effective:r--  (mask limits bob's write)
group::r--              #effective:r-- 
mask::r-x               # chmod affected the mask
other::---

chmod and ACL Mask Interaction

When you run chmod on a file with extended ACL entries, the group permission bits actually modify the ACL mask, not the owning group's permissions. This is a common source of confusion. If chmod g-w breaks application access, the mask reduction is likely affecting named user/group entries. Always use getfacl to see actual effective permissions.

Windows ACE Types

Windows provides a richer set of ACE types, supporting not just allow and deny but also auditing and special system-level controls. ACEs are classified into two main categories based on which ACL they appear in:

Discretionary Access Control List (DACL): Controls who can access the object
System Access Control List (SACL): Controls what access attempts are audited

Windows ACE Types
ACE Type	ACL Type	Description
ACCESS_ALLOWED_ACE	DACL	Grants specified permissions to the SID
ACCESS_DENIED_ACE	DACL	Explicitly denies specified permissions to the SID
ACCESS_ALLOWED_OBJECT_ACE	DACL	Grants permissions to specific properties/child object types (AD)
ACCESS_DENIED_OBJECT_ACE	DACL	Denies permissions to specific properties/child object types (AD)
SYSTEM_AUDIT_ACE	SACL	Generates audit events for specified access attempts
SYSTEM_ALARM_ACE	SACL	Reserved for system alerts (rarely used)
SYSTEM_AUDIT_OBJECT_ACE	SACL	Audits access to specific properties/child types (AD)
ACCESS_ALLOWED_CALLBACK_ACE	DACL	Dynamic access evaluation via callback function
SYSTEM_MANDATORY_LABEL_ACE	SACL	Integrity level control (Vista+)

Windows ACE Binary Structure
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
// Windows ACE header (common to all ACE types)
typedef struct _ACE_HEADER {
    BYTE  AceType;     // Type of ACE (ACCESS_ALLOWED, ACCESS_DENIED, etc.)
    BYTE  AceFlags;    // Inheritance and audit flags
    WORD  AceSize;     // Total size of ACE in bytes
} ACE_HEADER;
 
// Standard ACE structure (ACCESS_ALLOWED_ACE, ACCESS_DENIED_ACE)
typedef struct _ACCESS_ALLOWED_ACE {
    ACE_HEADER  Header;
    ACCESS_MASK Mask;      // 32-bit permission mask
    DWORD       SidStart;  // Start of variable-length SID
} ACCESS_ALLOWED_ACE;
 
// ACE flags for inheritance and auditing
#define OBJECT_INHERIT_ACE         0x01  // Child objects inherit
#define CONTAINER_INHERIT_ACE      0x02  // Child containers inherit  
#define NO_PROPAGATE_INHERIT_ACE   0x04  // Don't propagate to grandchildren
#define INHERIT_ONLY_ACE           0x08  // Don't apply to this object
#define INHERITED_ACE              0x10  // This ACE was inherited
#define SUCCESSFUL_ACCESS_ACE_FLAG 0x40  // Audit successful access (SACL)
#define FAILED_ACCESS_ACE_FLAG     0x80  // Audit failed access (SACL)
 
// Example: Allow Read for "Users" group with inheritance
// ACE Type:    ACCESS_ALLOWED_ACE (0x00)
// ACE Flags:   CONTAINER_INHERIT | OBJECT_INHERIT (0x03)
// Access Mask: FILE_GENERIC_READ (0x00120089)
// SID:         S-1-5-32-545 (BUILTIN\Users)

Viewing Windows ACEs with icacls and PowerShell:

Windows ACE Commands
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
# Using icacls to view DACL entries
C:\> icacls C:\Projects\secret.txt
 
C:\Projects\secret.txt
  NT AUTHORITY\SYSTEM:(F)        # Full control
  BUILTIN\Administrators:(F)     # Full control
  CONTOSO\alice:(M)              # Modify
  CONTOSO\bob:(R)               # Read (allowed)
  CONTOSO\eve:(D)               # Deny (if preceded by deny flag)
 
# Permission key:
# F = Full Control        R = Read
# M = Modify              W = Write
# RX = Read + Execute     D = Delete
# (OI) = Object Inherit   (CI) = Container Inherit
# (IO) = Inherit Only     (NP) = No Propagate
 
# Using PowerShell to see complete ACE details
$acl = Get-Acl "C:\Projects\secret.txt"
$acl.Access | Format-List
 
# Output:
# FileSystemRights  : Read, Synchronize
# AccessControlType : Allow
# IdentityReference : CONTOSO\bob
# IsInherited       : False
# InheritanceFlags  : None
# PropagationFlags  : None
 
# To see DACL in SDDL format (Security Descriptor Definition Language):
$acl.Sddl
# O:BA                    # Owner: BUILTIN\Administrators
# G:BA                    # Group: BUILTIN\Administrators  
# D:PAI                   # DACL: Protected, Auto-Inherited
# (A;;FA;;;SY)           # Allow Full Access to SYSTEM
# (A;;FA;;;BA)           # Allow Full Access to Administrators
# (A;;0x1301bf;;;S-1-5-21-...) # Allow specific permissions to SID

Understanding SDDL

SDDL (Security Descriptor Definition Language) is Windows' text format for security descriptors. The format is 'ACE_TYPE;ACE_FLAGS;ACCESS_MASK;OBJECT_GUID;INHERIT_OBJECT_GUID;SID'. For example, '(A;;FA;;;BA)' means Allow (A), no flags, Full Access (FA), to BUILTIN\Administrators (BA). SDDL is essential for scripted security configuration and backups.

Permission Bitmasks in Detail

The permission mask (or access mask) is the heart of every ACE, specifying exactly which operations are allowed or denied. Both POSIX and Windows use bitmasks, but Windows provides much finer granularity.

POSIX Permission Bits:

POSIX uses a simple 3-bit mask for each entry:

POSIX ACL Permission Bits
Bit	Value	Symbol	File Meaning	Directory Meaning
Bit 2	4	r (read)	Read file contents	List directory contents (ls)
Bit 1	2	w (write)	Modify file contents	Create/delete files in directory
Bit 0	1	x (execute)	Execute as program	Enter directory (cd), access files within

Windows Access Mask:

Windows uses a 32-bit access mask with both generic and object-specific permissions. The complete mask structure is:

Windows 32-bit Access Mask Structure
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
// Windows ACCESS_MASK is a 32-bit value:
// 
// 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
// ├──┴──┴──┴──┤  │  │  │  │  │  │  │  ├──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┤
// Generic Rights SA MA WO WD Rsvd │  │     Standard Rights        Object-Specific Rights
//                                AC  SC
//
// Bits 28-31: Generic rights (mapped to standard + specific by object type)
// Bit 27: MAXIMUM_ALLOWED (request maximum permissions)
// Bit 26-25: Reserved  
// Bit 24: ACCESS_SYSTEM_SECURITY (read/write SACL)
// Bit 23-16: Standard access rights (common to all objects)
// Bit 15-0:  Object-specific access rights
 
// Generic Rights (bits 28-31)
#define GENERIC_ALL         0x10000000  // All permissions
#define GENERIC_EXECUTE     0x20000000  // Execute/traverse
#define GENERIC_WRITE       0x40000000  // Write data
#define GENERIC_READ        0x80000000  // Read data
 
// Standard Rights (bits 16-23)
#define DELETE              0x00010000  // Delete the object
#define READ_CONTROL        0x00020000  // Read security descriptor
#define WRITE_DAC           0x00040000  // Modify DACL
#define WRITE_OWNER         0x00080000  // Change owner
#define SYNCHRONIZE         0x00100000  // Use for synchronization
 
// File-Specific Rights (bits 0-15)
#define FILE_READ_DATA          0x0001  // Read file contents
#define FILE_WRITE_DATA         0x0002  // Write file contents
#define FILE_APPEND_DATA        0x0004  // Append data
#define FILE_READ_EA            0x0008  // Read extended attributes
#define FILE_WRITE_EA           0x0010  // Write extended attributes
#define FILE_EXECUTE            0x0020  // Execute file
#define FILE_DELETE_CHILD       0x0040  // Delete children (directories)
#define FILE_READ_ATTRIBUTES    0x0080  // Read file attributes
#define FILE_WRITE_ATTRIBUTES   0x0100  // Write file attributes
 
// Common composite rights
#define FILE_GENERIC_READ    (STANDARD_RIGHTS_READ | FILE_READ_DATA | \
                              FILE_READ_ATTRIBUTES | FILE_READ_EA | SYNCHRONIZE)
                             // = 0x00120089
 
#define FILE_GENERIC_WRITE   (STANDARD_RIGHTS_WRITE | FILE_WRITE_DATA | \
                              FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA | \
                              FILE_APPEND_DATA | SYNCHRONIZE)
                             // = 0x00120116
 
#define FILE_GENERIC_EXECUTE (STANDARD_RIGHTS_EXECUTE | FILE_READ_ATTRIBUTES | \
                              FILE_EXECUTE | SYNCHRONIZE)
                             // = 0x001200A0
 
#define FILE_ALL_ACCESS      (STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0x1FF)
                             // = 0x001F01FF

Granular Permissions Enable

•Append-only access: Grant APPEND_DATA but deny WRITE_DATA
•Attribute modification only: Allow WRITE_ATTRIBUTES without data write
•Execute without read: Allow EXECUTE but deny READ_DATA (common for scripts)
•Ownership transfer: Grant WRITE_OWNER without full control
•Security modification: Grant WRITE_DAC to delegate ACL management

POSIX Limitations

•Cannot grant append without general write
•Cannot separate attribute from data modification
•No permission to change ACL itself (owner only)
•No ownership transfer permission
•Audit requires separate systems (auditd)

NFSv4 ACLs: Bridging the Gap

NFSv4 ACLs were designed to bridge POSIX simplicity with Windows granularity. NFSv4 ACLs support 14 permission bits including READ_DATA, WRITE_DATA, APPEND_DATA, READ_ACL, WRITE_ACL, and more. Linux supports NFSv4 ACLs on some file systems (like ZFS), providing Windows-compatible fine-grained permissions on Unix systems.

Subject Identifiers: UIDs, GIDs, and SIDs

Each ACE must identify who it applies to. This requires robust, unambiguous identification of security principals across system boundaries. The subject identifier mechanisms differ significantly between Unix and Windows.

POSIX: User IDs (UIDs) and Group IDs (GIDs)

Unix systems use simple 32-bit integers to identify users and groups. While simple, this approach has limitations in federated environments:

POSIX Subject Identifiers
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
# UIDs and GIDs are simple integers
$ id alice
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),100(users)
 
# In ACL entries, UIDs/GIDs are stored as 32-bit integers
$ getfacl -n /project/file.txt    # -n shows numeric IDs
# file: project/file.txt
# owner: 1000
# group: 100
user::rw-
user:1001:r--           # UID 1001 (bob)
user:1002:rw-           # UID 1002 (charlie)
group::r--
group:200:r--           # GID 200 (marketing)
mask::rw-
other::---
 
# UID/GID mapping is resolved through NSS (Name Service Switch)
$ getent passwd 1000
alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash
 
# Well-known IDs:
# UID 0: root (superuser)
# GID 0: root/wheel group
# UID 65534: nobody (unmapped/overflow)
# GID 65534: nogroup
 
# Limitations:
# 1. IDs are local to the system (or must be synchronized)
# 2. No way to distinguish "alice from server A" vs "alice from server B"
# 3. Backup/restore across systems requires UID mapping
# 4. No inherent structure or hierarchy

Windows: Security Identifiers (SIDs)

Windows uses variable-length Security Identifiers that provide global uniqueness and support for domains and trust relationships:

Windows Security Identifiers
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
# SID Format: S-R-I-SA-SA-...-RID
# S  = Literal 'S' (identifies as SID)
# R  = Revision (always 1)
# I  = Identifier Authority (who issued the SID)
# SA = Subauthority values (domain/machine identifiers)
# RID = Relative ID (unique within the authority)
 
# Example SID breakdown:
# S-1-5-21-3623811015-3361044348-30300820-1013
# │ │ │  └──────────────────────────────┘  └─┘
# │ │ │              Domain ID            RID
# │ │ └── Identifier Authority: 5 = NT Authority
# │ └──── Revision: 1
# └────── SID marker
 
# Well-known SIDs:
S-1-1-0           # Everyone (World)
S-1-5-18          # SYSTEM (LocalSystem account)
S-1-5-19          # LOCAL SERVICE
S-1-5-20          # NETWORK SERVICE
S-1-5-32-544      # BUILTIN\Administrators
S-1-5-32-545      # BUILTIN\Users
S-1-5-11          # Authenticated Users
 
# View account SID
C:\> wmic useraccount where name='alice' get sid
SID
S-1-5-21-3623811015-3361044348-30300820-1013
 
# Convert SID to name
C:\> powershell -c "(New-Object System.Security.Principal.SecurityIdentifier('S-1-5-32-544')).Translate([System.Security.Principal.NTAccount]).Value"
BUILTIN\Administrators
 
# SID advantages:
# 1. Globally unique (domain SID + RID ensures uniqueness)
# 2. Survives username changes (SID remains same)
# 3. Supports cross-domain/forest references
# 4. Includes creation authority information
# 5. Backup/restore preserves exact identities

Subject Identifier Comparison
Feature	POSIX UID/GID	Windows SID
Size	Fixed 32 bits	Variable (8-68 bytes typically)
Uniqueness	Local to system/namespace	Globally unique
Username change	Requires no update	Requires no update (both decouple name from ID)
Cross-system identity	Manual synchronization needed	Built-in domain support
Readability	Simple integer	Complex string/binary
Special identifiers	0=root, 65534=nobody	Well-known SIDs for many built-in accounts
Group hierarchy	Flat namespace	Supports nested groups

ACL Portability Challenges

When moving files between systems, ACL subject identifiers may become orphaned if the referenced UID/SID doesn't exist on the target system. Unix shows numeric IDs for unknown users; Windows shows 'Account Unknown' or raw SIDs. Always use ACL-aware copy tools (rsync -A, robocopy /SEC) and verify identity resolution after migration.

Constructing ACL Entries in Practice

Now let's apply our knowledge to construct ACL entries for real-world scenarios. We'll cover both POSIX and Windows approaches for common access control requirements.

Scenario 1: Shared Project Directory

Requirements:

Project lead (alice): Full control
Development team (devteam group): Read, write, execute
QA team (qa group): Read and execute only
External auditor (auditor): Read only
Contractor (contractor): No access (explicit deny)

POSIX ACL Construction
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
# Create directory and set owner
$ mkdir /projects/alpha
$ chown alice:devteam /projects/alpha
 
# Set base permissions with setfacl
# -m = modify (add or update entries)
 
# Owner gets full control (this is set via USER_OBJ)
$ setfacl -m u::rwx /projects/alpha
 
# Development team (owning group) gets rwx
$ setfacl -m g::rwx /projects/alpha
 
# QA team gets read + execute
$ setfacl -m g:qa:rx /projects/alpha
 
# Auditor gets read only (and execute for directory traversal)
$ setfacl -m u:auditor:rx /projects/alpha
 
# Contractor gets explicit deny (empty permission set)
$ setfacl -m u:contractor:--- /projects/alpha
 
# Others get no access
$ setfacl -m o::--- /projects/alpha
 
# Set the mask to allow full permissions for named entries
$ setfacl -m m::rwx /projects/alpha
 
# Verify the complete ACL
$ getfacl /projects/alpha
# file: projects/alpha
# owner: alice
# group: devteam
user::rwx
user:auditor:r-x
user:contractor:---
group::rwx
group:qa:r-x
mask::rwx
other::---
 
# Set default ACL for inheritance (new files/dirs get these ACLs)
$ setfacl -d -m u::rwx /projects/alpha
$ setfacl -d -m g::rwx /projects/alpha
$ setfacl -d -m g:qa:rx /projects/alpha
$ setfacl -d -m u:auditor:rx /projects/alpha
$ setfacl -d -m u:contractor:--- /projects/alpha
$ setfacl -d -m o::--- /projects/alpha
$ setfacl -d -m m::rwx /projects/alpha
 
$ getfacl /projects/alpha
# file: projects/alpha
# owner: alice
# group: devteam
user::rwx
user:auditor:r-x
user:contractor:---
group::rwx
group:qa:r-x
mask::rwx
other::---
default:user::rwx
default:user:auditor:r-x
default:user:contractor:---
default:group::rwx
default:group:qa:r-x
default:mask::rwx
default:other::---

ACE Ordering Matters in Windows

Notice that in the Windows icacls output, the DENY ACE for contractor appears first. Windows canonically orders ACEs with explicit deny before allow, and inherited entries after non-inherited. The icacls and PowerShell cmdlets handle this ordering automatically, but if you manipulate ACLs programmatically, ensure proper ordering or access checks may not behave as expected.

Entry Flags and Special Modifiers

ACE flags modify how entries are interpreted and inherited. Understanding these flags is essential for creating ACLs that behave correctly as files and directories are created, copied, and modified.

Windows ACE Flags:

Windows ACE Inheritance Flags
Flag	icacls	Effect
OBJECT_INHERIT_ACE	(OI)	ACE is inherited by files in this directory
CONTAINER_INHERIT_ACE	(CI)	ACE is inherited by subdirectories
NO_PROPAGATE_INHERIT_ACE	(NP)	Inheritance stops at immediate children
INHERIT_ONLY_ACE	(IO)	ACE applies only to children, not this object
INHERITED_ACE	(I)	Indicates this ACE was inherited (not explicit)

Inheritance Flag Combinations
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
# Common inheritance patterns:
 
# Full inheritance (directories and files, all levels)
(OI)(CI)    # Container + Object inherit
 
# Files only (not subdirectories)
(OI)        # Object inherit only
 
# Subdirectories only (not files)
(CI)        # Container inherit only
 
# Immediate children only (no grandchildren)
(OI)(CI)(NP)  # Object + Container + No Propagate
 
# Children only, not this directory itself
(OI)(CI)(IO)  # Inherit-only: ACE applies to new items, not this dir
 
# Example: Log directory structure
# /logs
#   - Admins: Full control (including this dir and all descendants)
#   - LogService: Write new files only (can't read, can't delete)
#   - Auditors: Read existing files only (can't create new)
 
C:\> icacls C:\Logs /inheritance:r
C:\> icacls C:\Logs /grant "Administrators:(OI)(CI)F"
 
# LogService can create files (write to directory) but inherit-only
# means the permission applies to files it creates
C:\> icacls C:\Logs /grant "LogService:(CI)WD"      # Write to directory
C:\> icacls C:\Logs /grant "LogService:(OI)(IO)M"   # Modify files (IO=children only)
 
# Auditors can only read existing files, not create new ones
C:\> icacls C:\Logs /grant "Auditors:(OI)R"    # Read files
# Note: No (CI) means subdirs don't inherit
# No write to directory means can't create files

POSIX Default ACLs (Inheritance Equivalent):

POSIX uses a separate "default ACL" on directories rather than flags on individual entries. The default ACL specifies what ACL new entries should receive:

POSIX Default ACL Behavior
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
# Default ACLs only exist on directories
# They specify the access ACL that new files/directories will receive
 
# Set a default ACL on a directory
$ setfacl -d -m u::rwx,g::rx,o::---,u:bob:rx /shared
 
# View default ACL (prefixed with "default:")
$ getfacl /shared
# file: shared
# owner: alice
# group: staff
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:bob:r-x
default:group::r-x
default:mask::r-x
default:other::---
 
# When a new file is created:
$ touch /shared/newfile.txt
$ getfacl /shared/newfile.txt
# file: shared/newfile.txt
# owner: alice
# group: staff
user::rw-           # From default (modified by umask for files)
user:bob:r--        # Bob inherited from default
group::r--
mask::r--
other::---
 
# New directories inherit both access and default ACLs:
$ mkdir /shared/subdir
$ getfacl /shared/subdir
# file: shared/subdir
# owner: alice  
# group: staff
user::rwx
user:bob:r-x
group::r-x
mask::r-x
other::---
default:user::rwx
default:user:bob:r-x
default:group::r-x
default:mask::r-x
default:other::---   # Default ACL is also inherited!

Execute Bit Inheritance Caveat

In POSIX, even when the default ACL includes execute permission, newly created files do not receive execute permission unless the creating process explicitly requests it. This is a safety feature—text files shouldn't become executable. Directories always get execute bits from the default ACL because execute on a directory means 'searchable', not 'executable'.

Summary: Mastering ACL Entries

ACL entries are the fundamental building blocks of fine-grained access control. Mastering their construction and interpretation is essential for implementing secure, functional access policies. Let's consolidate the key concepts:

Key Takeaways

•ACEs have four core components — Entry type (allow/deny), subject identifier (UID/SID), permission mask, and flags. All are required for complete specification.
•POSIX provides six entry types — USER_OBJ, USER, GROUP_OBJ, GROUP, MASK, and OTHER. The MASK entry bounds named user/group permissions.
•Windows offers richer ACE types — Including explicit deny, object-specific ACEs, audit ACEs, and callback ACEs for dynamic evaluation.
•Permission granularity differs significantly — POSIX has 3 bits (rwx); Windows has 32 bits with object-specific meanings enabling fine-grained control.
•Subject identifiers must be globally unambiguous — POSIX UIDs are local; Windows SIDs are globally unique across domains.
•Inheritance flags control propagation — Windows uses per-ACE flags; POSIX uses separate default ACLs on directories.

What's Next:

With ACL entries mastered, we'll explore default permissions in the next page. You'll learn how systems determine the initial ACL for newly created objects, how umask and default ACLs interact, and how to configure sensible defaults for different environments.

Page Complete

You now have deep knowledge of ACL entry anatomy across POSIX and Windows systems. You understand entry types, permission bitmasks, subject identifiers, and inheritance flags. You can construct precise ACL entries for complex access control requirements. Next, we'll explore how default permissions work when new objects are created.

2 / 5

Loading learning content...

Operating SystemsAccess Control Lists

Access Control Lists

LevelIntermediate

Duration90 mins

TopicAccess Control Lists

2 / 5

ACL Entries

The Building Blocks of Access Control

What You Will Learn

Anatomy of an Access Control Entry

Every Access Control Entry, regardless of operating system, contains the same conceptual components. Understanding this universal structure enables you to work effectively across platforms.

Universal ACE Structure:

┌─────────────────────────────────────────────────────────────────┐
│                    Access Control Entry (ACE)                    │
├─────────────────────────────────────────────────────────────────┤
│                                                                  │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────────────┐  │
│  │  Entry Type  │  │   Subject    │  │   Permission Mask    │  │
│  │              │  │  Identifier  │  │                      │  │
│  │  - Allow     │  │              │  │  - Read              │  │
│  │  - Deny      │  │  - User ID   │  │  - Write             │  │
│  │  - Audit     │  │  - Group ID  │  │  - Execute           │  │
│  │              │  │  - SID       │  │  - Delete            │  │
│  │              │  │              │  │  - etc.              │  │
│  └──────────────┘  └──────────────┘  └──────────────────────┘  │
│                                                                  │
│  ┌────────────────────────────────────────────────────────────┐ │
│  │                          Flags                              │ │
│  │  - Inheritance (container, object, inherit-only)           │ │
│  │  - Inheritance propagation controls                        │ │
│  │  - Audit success/failure selection                         │ │
│  └────────────────────────────────────────────────────────────┘ │
│                                                                  │
└─────────────────────────────────────────────────────────────────┘

Core ACE Components

•Entry Type (Tag): Specifies whether this entry allows or denies access (or triggers an audit). In POSIX, the tag also identifies whether this is a named user, named group, or a special entry type like mask.
•Subject Identifier: Who this entry applies to. In POSIX, this is a UID or GID. In Windows, this is a Security Identifier (SID). Special identifiers exist for groups like 'Everyone' or 'Authenticated Users'.
•Permission Mask (Access Mask): A bitmask specifying which operations are affected by this entry. Each bit represents a specific permission like read, write, execute, delete, or change_permissions.
•Flags (optional): Additional control bits that modify how the entry is interpreted, particularly regarding inheritance and auditing.

Platform Terminology

POSIX ACL Entry Types

The Six POSIX ACL Entry Types:

POSIX ACL Entry Types (Access ACL)
Tag Type	Qualifier	Description	Traditional Mapping
ACL_USER_OBJ	None (implied owner)	Permissions for the file owner	Owner bits (rwx------) of mode
ACL_USER	UID of named user	Permissions for a specific user by UID	No traditional equivalent
ACL_GROUP_OBJ	None (implied group)	Permissions for the owning group	Group bits (---rwx---) of mode
ACL_GROUP	GID of named group	Permissions for a specific group by GID	No traditional equivalent
ACL_MASK	None	Maximum permissions for named users and groups	Intersects with group bits in mode
ACL_OTHER	None	Permissions for everyone else	Other bits (------rwx) of mode

POSIX ACL Entry Examples
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
# View and understand each entry type
$ getfacl /project/document.txt
# file: project/document.txt
# owner: alice
# group: engineering
 
user::rw-               # ACL_USER_OBJ: alice (owner) has read+write
user:bob:r--            # ACL_USER: bob specifically has read-only
user:charlie:rw-        # ACL_USER: charlie has read+write
group::r--              # ACL_GROUP_OBJ: engineering group has read
group:marketing:r--     # ACL_GROUP: marketing group has read
group:executives:rw-    # ACL_GROUP: executives group has read+write
mask::rw-               # ACL_MASK: maximum for named users/groups is rw
other::---              # ACL_OTHER: everyone else has no access
 
# Internal representation (struct acl_entry):
struct acl_entry {
    acl_tag_t   e_tag;    /* ACL_USER_OBJ, ACL_USER, etc. */
    acl_perm_t  e_perm;   /* Permission bits (r=4, w=2, x=1) */
    id_t        e_id;     /* UID or GID (undefined for _OBJ types) */
};
 
# Binary representation in extended attribute:
# Each entry = 8 bytes: tag(2) + perm(2) + id(4)
# 
# Example for user:bob:r--
#   tag:  0x0001 (ACL_USER)
#   perm: 0x0004 (read only)
#   id:   0x000003E8 (UID 1000, typical first user)

The Critical Role of ACL_MASK:

Understanding the Mask Entry
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
# Scenario: We want bob to have read+write, but temporarily restrict all 
# extended permissions to read-only
 
# Initial ACL
$ getfacl file.txt
user::rw-
user:bob:rw-
group::r--
mask::rw-
other::---
 
# Effective permissions: bob has rw- (his entry AND mask = rw-)
 
# Now reduce the mask to read-only
$ setfacl -m m::r-- file.txt
$ getfacl file.txt
user::rw-               # NOT affected by mask (still rw-)
user:bob:rw-            #effective:r--
group::r--              #effective:r--
mask::r--               # Mask is now read-only
other::---              # NOT affected by mask
 
# Bob's STORED permissions are still rw-, but his EFFECTIVE permissions
# are r-- because: stored_perms & mask = rw- & r-- = r--
 
# The #effective: comment shows actual permissions after mask application
 
# This is powerful for temporary restrictions:
# - Set mask to r-- during maintenance: everyone gets read-only
# - Restore mask to rwx after: original permissions are restored
# - No need to modify individual entries!
 
# chmod on a file with ACL updates the mask, not just group bits:
$ chmod g=rx file.txt    # This sets the MASK to r-x, not the group!
$ getfacl file.txt
user::rw-
user:bob:rw-            #effective:r--  (mask limits bob's write)
group::r--              #effective:r-- 
mask::r-x               # chmod affected the mask
other::---

chmod and ACL Mask Interaction

Windows ACE Types

Discretionary Access Control List (DACL): Controls who can access the object
System Access Control List (SACL): Controls what access attempts are audited

Windows ACE Types
ACE Type	ACL Type	Description
ACCESS_ALLOWED_ACE	DACL	Grants specified permissions to the SID
ACCESS_DENIED_ACE	DACL	Explicitly denies specified permissions to the SID
ACCESS_ALLOWED_OBJECT_ACE	DACL	Grants permissions to specific properties/child object types (AD)
ACCESS_DENIED_OBJECT_ACE	DACL	Denies permissions to specific properties/child object types (AD)
SYSTEM_AUDIT_ACE	SACL	Generates audit events for specified access attempts
SYSTEM_ALARM_ACE	SACL	Reserved for system alerts (rarely used)
SYSTEM_AUDIT_OBJECT_ACE	SACL	Audits access to specific properties/child types (AD)
ACCESS_ALLOWED_CALLBACK_ACE	DACL	Dynamic access evaluation via callback function
SYSTEM_MANDATORY_LABEL_ACE	SACL	Integrity level control (Vista+)

Windows ACE Binary Structure
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
// Windows ACE header (common to all ACE types)
typedef struct _ACE_HEADER {
    BYTE  AceType;     // Type of ACE (ACCESS_ALLOWED, ACCESS_DENIED, etc.)
    BYTE  AceFlags;    // Inheritance and audit flags
    WORD  AceSize;     // Total size of ACE in bytes
} ACE_HEADER;
 
// Standard ACE structure (ACCESS_ALLOWED_ACE, ACCESS_DENIED_ACE)
typedef struct _ACCESS_ALLOWED_ACE {
    ACE_HEADER  Header;
    ACCESS_MASK Mask;      // 32-bit permission mask
    DWORD       SidStart;  // Start of variable-length SID
} ACCESS_ALLOWED_ACE;
 
// ACE flags for inheritance and auditing
#define OBJECT_INHERIT_ACE         0x01  // Child objects inherit
#define CONTAINER_INHERIT_ACE      0x02  // Child containers inherit  
#define NO_PROPAGATE_INHERIT_ACE   0x04  // Don't propagate to grandchildren
#define INHERIT_ONLY_ACE           0x08  // Don't apply to this object
#define INHERITED_ACE              0x10  // This ACE was inherited
#define SUCCESSFUL_ACCESS_ACE_FLAG 0x40  // Audit successful access (SACL)
#define FAILED_ACCESS_ACE_FLAG     0x80  // Audit failed access (SACL)
 
// Example: Allow Read for "Users" group with inheritance
// ACE Type:    ACCESS_ALLOWED_ACE (0x00)
// ACE Flags:   CONTAINER_INHERIT | OBJECT_INHERIT (0x03)
// Access Mask: FILE_GENERIC_READ (0x00120089)
// SID:         S-1-5-32-545 (BUILTIN\Users)

Viewing Windows ACEs with icacls and PowerShell:

Windows ACE Commands
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
# Using icacls to view DACL entries
C:\> icacls C:\Projects\secret.txt
 
C:\Projects\secret.txt
  NT AUTHORITY\SYSTEM:(F)        # Full control
  BUILTIN\Administrators:(F)     # Full control
  CONTOSO\alice:(M)              # Modify
  CONTOSO\bob:(R)               # Read (allowed)
  CONTOSO\eve:(D)               # Deny (if preceded by deny flag)
 
# Permission key:
# F = Full Control        R = Read
# M = Modify              W = Write
# RX = Read + Execute     D = Delete
# (OI) = Object Inherit   (CI) = Container Inherit
# (IO) = Inherit Only     (NP) = No Propagate
 
# Using PowerShell to see complete ACE details
$acl = Get-Acl "C:\Projects\secret.txt"
$acl.Access | Format-List
 
# Output:
# FileSystemRights  : Read, Synchronize
# AccessControlType : Allow
# IdentityReference : CONTOSO\bob
# IsInherited       : False
# InheritanceFlags  : None
# PropagationFlags  : None
 
# To see DACL in SDDL format (Security Descriptor Definition Language):
$acl.Sddl
# O:BA                    # Owner: BUILTIN\Administrators
# G:BA                    # Group: BUILTIN\Administrators  
# D:PAI                   # DACL: Protected, Auto-Inherited
# (A;;FA;;;SY)           # Allow Full Access to SYSTEM
# (A;;FA;;;BA)           # Allow Full Access to Administrators
# (A;;0x1301bf;;;S-1-5-21-...) # Allow specific permissions to SID

Understanding SDDL

Permission Bitmasks in Detail

POSIX Permission Bits:

POSIX uses a simple 3-bit mask for each entry:

POSIX ACL Permission Bits
Bit	Value	Symbol	File Meaning	Directory Meaning
Bit 2	4	r (read)	Read file contents	List directory contents (ls)
Bit 1	2	w (write)	Modify file contents	Create/delete files in directory
Bit 0	1	x (execute)	Execute as program	Enter directory (cd), access files within

Windows Access Mask:

Windows uses a 32-bit access mask with both generic and object-specific permissions. The complete mask structure is:

Windows 32-bit Access Mask Structure
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
// Windows ACCESS_MASK is a 32-bit value:
// 
// 31 30 29 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 12 11 10 09 08 07 06 05 04 03 02 01 00
// ├──┴──┴──┴──┤  │  │  │  │  │  │  │  ├──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┴──┤
// Generic Rights SA MA WO WD Rsvd │  │     Standard Rights        Object-Specific Rights
//                                AC  SC
//
// Bits 28-31: Generic rights (mapped to standard + specific by object type)
// Bit 27: MAXIMUM_ALLOWED (request maximum permissions)
// Bit 26-25: Reserved  
// Bit 24: ACCESS_SYSTEM_SECURITY (read/write SACL)
// Bit 23-16: Standard access rights (common to all objects)
// Bit 15-0:  Object-specific access rights
 
// Generic Rights (bits 28-31)
#define GENERIC_ALL         0x10000000  // All permissions
#define GENERIC_EXECUTE     0x20000000  // Execute/traverse
#define GENERIC_WRITE       0x40000000  // Write data
#define GENERIC_READ        0x80000000  // Read data
 
// Standard Rights (bits 16-23)
#define DELETE              0x00010000  // Delete the object
#define READ_CONTROL        0x00020000  // Read security descriptor
#define WRITE_DAC           0x00040000  // Modify DACL
#define WRITE_OWNER         0x00080000  // Change owner
#define SYNCHRONIZE         0x00100000  // Use for synchronization
 
// File-Specific Rights (bits 0-15)
#define FILE_READ_DATA          0x0001  // Read file contents
#define FILE_WRITE_DATA         0x0002  // Write file contents
#define FILE_APPEND_DATA        0x0004  // Append data
#define FILE_READ_EA            0x0008  // Read extended attributes
#define FILE_WRITE_EA           0x0010  // Write extended attributes
#define FILE_EXECUTE            0x0020  // Execute file
#define FILE_DELETE_CHILD       0x0040  // Delete children (directories)
#define FILE_READ_ATTRIBUTES    0x0080  // Read file attributes
#define FILE_WRITE_ATTRIBUTES   0x0100  // Write file attributes
 
// Common composite rights
#define FILE_GENERIC_READ    (STANDARD_RIGHTS_READ | FILE_READ_DATA | \
                              FILE_READ_ATTRIBUTES | FILE_READ_EA | SYNCHRONIZE)
                             // = 0x00120089
 
#define FILE_GENERIC_WRITE   (STANDARD_RIGHTS_WRITE | FILE_WRITE_DATA | \
                              FILE_WRITE_ATTRIBUTES | FILE_WRITE_EA | \
                              FILE_APPEND_DATA | SYNCHRONIZE)
                             // = 0x00120116
 
#define FILE_GENERIC_EXECUTE (STANDARD_RIGHTS_EXECUTE | FILE_READ_ATTRIBUTES | \
                              FILE_EXECUTE | SYNCHRONIZE)
                             // = 0x001200A0
 
#define FILE_ALL_ACCESS      (STANDARD_RIGHTS_REQUIRED | SYNCHRONIZE | 0x1FF)
                             // = 0x001F01FF

Granular Permissions Enable

•Append-only access: Grant APPEND_DATA but deny WRITE_DATA
•Attribute modification only: Allow WRITE_ATTRIBUTES without data write
•Execute without read: Allow EXECUTE but deny READ_DATA (common for scripts)
•Ownership transfer: Grant WRITE_OWNER without full control
•Security modification: Grant WRITE_DAC to delegate ACL management

POSIX Limitations

•Cannot grant append without general write
•Cannot separate attribute from data modification
•No permission to change ACL itself (owner only)
•No ownership transfer permission
•Audit requires separate systems (auditd)

NFSv4 ACLs: Bridging the Gap

Subject Identifiers: UIDs, GIDs, and SIDs

POSIX: User IDs (UIDs) and Group IDs (GIDs)

Unix systems use simple 32-bit integers to identify users and groups. While simple, this approach has limitations in federated environments:

POSIX Subject Identifiers
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
# UIDs and GIDs are simple integers
$ id alice
uid=1000(alice) gid=1000(alice) groups=1000(alice),27(sudo),100(users)
 
# In ACL entries, UIDs/GIDs are stored as 32-bit integers
$ getfacl -n /project/file.txt    # -n shows numeric IDs
# file: project/file.txt
# owner: 1000
# group: 100
user::rw-
user:1001:r--           # UID 1001 (bob)
user:1002:rw-           # UID 1002 (charlie)
group::r--
group:200:r--           # GID 200 (marketing)
mask::rw-
other::---
 
# UID/GID mapping is resolved through NSS (Name Service Switch)
$ getent passwd 1000
alice:x:1000:1000:Alice Smith:/home/alice:/bin/bash
 
# Well-known IDs:
# UID 0: root (superuser)
# GID 0: root/wheel group
# UID 65534: nobody (unmapped/overflow)
# GID 65534: nogroup
 
# Limitations:
# 1. IDs are local to the system (or must be synchronized)
# 2. No way to distinguish "alice from server A" vs "alice from server B"
# 3. Backup/restore across systems requires UID mapping
# 4. No inherent structure or hierarchy

Windows: Security Identifiers (SIDs)

Windows uses variable-length Security Identifiers that provide global uniqueness and support for domains and trust relationships:

Windows Security Identifiers
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
# SID Format: S-R-I-SA-SA-...-RID
# S  = Literal 'S' (identifies as SID)
# R  = Revision (always 1)
# I  = Identifier Authority (who issued the SID)
# SA = Subauthority values (domain/machine identifiers)
# RID = Relative ID (unique within the authority)
 
# Example SID breakdown:
# S-1-5-21-3623811015-3361044348-30300820-1013
# │ │ │  └──────────────────────────────┘  └─┘
# │ │ │              Domain ID            RID
# │ │ └── Identifier Authority: 5 = NT Authority
# │ └──── Revision: 1
# └────── SID marker
 
# Well-known SIDs:
S-1-1-0           # Everyone (World)
S-1-5-18          # SYSTEM (LocalSystem account)
S-1-5-19          # LOCAL SERVICE
S-1-5-20          # NETWORK SERVICE
S-1-5-32-544      # BUILTIN\Administrators
S-1-5-32-545      # BUILTIN\Users
S-1-5-11          # Authenticated Users
 
# View account SID
C:\> wmic useraccount where name='alice' get sid
SID
S-1-5-21-3623811015-3361044348-30300820-1013
 
# Convert SID to name
C:\> powershell -c "(New-Object System.Security.Principal.SecurityIdentifier('S-1-5-32-544')).Translate([System.Security.Principal.NTAccount]).Value"
BUILTIN\Administrators
 
# SID advantages:
# 1. Globally unique (domain SID + RID ensures uniqueness)
# 2. Survives username changes (SID remains same)
# 3. Supports cross-domain/forest references
# 4. Includes creation authority information
# 5. Backup/restore preserves exact identities

Subject Identifier Comparison
Feature	POSIX UID/GID	Windows SID
Size	Fixed 32 bits	Variable (8-68 bytes typically)
Uniqueness	Local to system/namespace	Globally unique
Username change	Requires no update	Requires no update (both decouple name from ID)
Cross-system identity	Manual synchronization needed	Built-in domain support
Readability	Simple integer	Complex string/binary
Special identifiers	0=root, 65534=nobody	Well-known SIDs for many built-in accounts
Group hierarchy	Flat namespace	Supports nested groups

ACL Portability Challenges

Constructing ACL Entries in Practice

Now let's apply our knowledge to construct ACL entries for real-world scenarios. We'll cover both POSIX and Windows approaches for common access control requirements.

Scenario 1: Shared Project Directory

Requirements:

Project lead (alice): Full control
Development team (devteam group): Read, write, execute
QA team (qa group): Read and execute only
External auditor (auditor): Read only
Contractor (contractor): No access (explicit deny)

POSIX ACL Construction
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
# Create directory and set owner
$ mkdir /projects/alpha
$ chown alice:devteam /projects/alpha
 
# Set base permissions with setfacl
# -m = modify (add or update entries)
 
# Owner gets full control (this is set via USER_OBJ)
$ setfacl -m u::rwx /projects/alpha
 
# Development team (owning group) gets rwx
$ setfacl -m g::rwx /projects/alpha
 
# QA team gets read + execute
$ setfacl -m g:qa:rx /projects/alpha
 
# Auditor gets read only (and execute for directory traversal)
$ setfacl -m u:auditor:rx /projects/alpha
 
# Contractor gets explicit deny (empty permission set)
$ setfacl -m u:contractor:--- /projects/alpha
 
# Others get no access
$ setfacl -m o::--- /projects/alpha
 
# Set the mask to allow full permissions for named entries
$ setfacl -m m::rwx /projects/alpha
 
# Verify the complete ACL
$ getfacl /projects/alpha
# file: projects/alpha
# owner: alice
# group: devteam
user::rwx
user:auditor:r-x
user:contractor:---
group::rwx
group:qa:r-x
mask::rwx
other::---
 
# Set default ACL for inheritance (new files/dirs get these ACLs)
$ setfacl -d -m u::rwx /projects/alpha
$ setfacl -d -m g::rwx /projects/alpha
$ setfacl -d -m g:qa:rx /projects/alpha
$ setfacl -d -m u:auditor:rx /projects/alpha
$ setfacl -d -m u:contractor:--- /projects/alpha
$ setfacl -d -m o::--- /projects/alpha
$ setfacl -d -m m::rwx /projects/alpha
 
$ getfacl /projects/alpha
# file: projects/alpha
# owner: alice
# group: devteam
user::rwx
user:auditor:r-x
user:contractor:---
group::rwx
group:qa:r-x
mask::rwx
other::---
default:user::rwx
default:user:auditor:r-x
default:user:contractor:---
default:group::rwx
default:group:qa:r-x
default:mask::rwx
default:other::---

ACE Ordering Matters in Windows

Entry Flags and Special Modifiers

ACE flags modify how entries are interpreted and inherited. Understanding these flags is essential for creating ACLs that behave correctly as files and directories are created, copied, and modified.

Windows ACE Flags:

Windows ACE Inheritance Flags
Flag	icacls	Effect
OBJECT_INHERIT_ACE	(OI)	ACE is inherited by files in this directory
CONTAINER_INHERIT_ACE	(CI)	ACE is inherited by subdirectories
NO_PROPAGATE_INHERIT_ACE	(NP)	Inheritance stops at immediate children
INHERIT_ONLY_ACE	(IO)	ACE applies only to children, not this object
INHERITED_ACE	(I)	Indicates this ACE was inherited (not explicit)

Inheritance Flag Combinations
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
# Common inheritance patterns:
 
# Full inheritance (directories and files, all levels)
(OI)(CI)    # Container + Object inherit
 
# Files only (not subdirectories)
(OI)        # Object inherit only
 
# Subdirectories only (not files)
(CI)        # Container inherit only
 
# Immediate children only (no grandchildren)
(OI)(CI)(NP)  # Object + Container + No Propagate
 
# Children only, not this directory itself
(OI)(CI)(IO)  # Inherit-only: ACE applies to new items, not this dir
 
# Example: Log directory structure
# /logs
#   - Admins: Full control (including this dir and all descendants)
#   - LogService: Write new files only (can't read, can't delete)
#   - Auditors: Read existing files only (can't create new)
 
C:\> icacls C:\Logs /inheritance:r
C:\> icacls C:\Logs /grant "Administrators:(OI)(CI)F"
 
# LogService can create files (write to directory) but inherit-only
# means the permission applies to files it creates
C:\> icacls C:\Logs /grant "LogService:(CI)WD"      # Write to directory
C:\> icacls C:\Logs /grant "LogService:(OI)(IO)M"   # Modify files (IO=children only)
 
# Auditors can only read existing files, not create new ones
C:\> icacls C:\Logs /grant "Auditors:(OI)R"    # Read files
# Note: No (CI) means subdirs don't inherit
# No write to directory means can't create files

POSIX Default ACLs (Inheritance Equivalent):

POSIX uses a separate "default ACL" on directories rather than flags on individual entries. The default ACL specifies what ACL new entries should receive:

POSIX Default ACL Behavior
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
# Default ACLs only exist on directories
# They specify the access ACL that new files/directories will receive
 
# Set a default ACL on a directory
$ setfacl -d -m u::rwx,g::rx,o::---,u:bob:rx /shared
 
# View default ACL (prefixed with "default:")
$ getfacl /shared
# file: shared
# owner: alice
# group: staff
user::rwx
group::rwx
other::r-x
default:user::rwx
default:user:bob:r-x
default:group::r-x
default:mask::r-x
default:other::---
 
# When a new file is created:
$ touch /shared/newfile.txt
$ getfacl /shared/newfile.txt
# file: shared/newfile.txt
# owner: alice
# group: staff
user::rw-           # From default (modified by umask for files)
user:bob:r--        # Bob inherited from default
group::r--
mask::r--
other::---
 
# New directories inherit both access and default ACLs:
$ mkdir /shared/subdir
$ getfacl /shared/subdir
# file: shared/subdir
# owner: alice  
# group: staff
user::rwx
user:bob:r-x
group::r-x
mask::r-x
other::---
default:user::rwx
default:user:bob:r-x
default:group::r-x
default:mask::r-x
default:other::---   # Default ACL is also inherited!

Execute Bit Inheritance Caveat

Summary: Mastering ACL Entries

Key Takeaways

•ACEs have four core components — Entry type (allow/deny), subject identifier (UID/SID), permission mask, and flags. All are required for complete specification.
•POSIX provides six entry types — USER_OBJ, USER, GROUP_OBJ, GROUP, MASK, and OTHER. The MASK entry bounds named user/group permissions.
•Windows offers richer ACE types — Including explicit deny, object-specific ACEs, audit ACEs, and callback ACEs for dynamic evaluation.
•Permission granularity differs significantly — POSIX has 3 bits (rwx); Windows has 32 bits with object-specific meanings enabling fine-grained control.
•Subject identifiers must be globally unambiguous — POSIX UIDs are local; Windows SIDs are globally unique across domains.
•Inheritance flags control propagation — Windows uses per-ACE flags; POSIX uses separate default ACLs on directories.

What's Next:

Page Complete

2 / 5