Access Control Lists - Learning Module

Loading content...

0/240

ACL Inheritance

Permissions That Flow Downward

Imagine managing permissions for a corporate file server with 500,000 files across 50,000 directories. If you had to set permissions individually on each file, you'd need an army of administrators working full-time. ACL inheritance solves this problem by allowing permissions to flow from parent containers to their children automatically.

But inheritance is a double-edged sword. Misconfigured inheritance can grant unintended access to vast swaths of files or, conversely, block legitimate access deep in a hierarchy. Understanding exactly how inheritance works, when it applies, and how to control it is critical for secure, manageable file systems.

This page provides expert-level knowledge of inheritance mechanics, enabling you to design and troubleshoot complex permission hierarchies.

What You Will Learn

By the end of this page, you will understand inheritance propagation mechanics in depth, be able to design multi-level inheritance hierarchies, know when and how to break inheritance, and be equipped to troubleshoot complex inheritance issues in enterprise environments.

The Philosophy of Inheritance

ACL inheritance embodies a fundamental principle: permissions should be defined at the broadest appropriate scope and flow to more specific objects. This principle provides several critical benefits:

Benefits of Permission Inheritance

•Administrative Efficiency — Define once at the parent, apply automatically to thousands of children. Reduces management overhead by orders of magnitude.
•Consistency — All children receive the same permissions from the parent, eliminating per-object configuration drift.
•Maintainability — Changing permissions at the parent automatically updates all inheriting children. No need to touch individual objects.
•Reduced Error — Fewer manual configurations means fewer opportunities for mistakes.
•Scalability — Permission management remains constant-time regardless of hierarchy depth or breadth.

The Inheritance Trade-off:

Inheritance introduces a tension between simplicity and granularity. Perfect inheritance would mean setting permissions once at the root and having them apply everywhere. But real organizations need exceptions: some directories more restrictive, some less, some with different access patterns.

The art of ACL design lies in finding the right balance: leveraging inheritance for common cases while using explicit ACEs and inheritance breaks for exceptions.

                           Inheritance Spectrum
                           
    ← Less Inheritance                     More Inheritance →
    
    ┌───────────────┬───────────────┬───────────────┬───────────────┐
    │  Every file   │  Some shared  │  Mostly       │  Single root  │
    │  has unique   │  patterns,    │  inherited,   │  ACL for      │
    │  ACL          │  many unique  │  few breaks   │  everything   │
    └───────────────┴───────────────┴───────────────┴───────────────┘
    
    Unmanageable        Practical          Ideal           Unrealistic
    (no inheritance)    (typical setup)    (well-designed) (no exceptions)

Design Principle: Inherit Down, Break Up

Start with the most permissive common case at the top of your hierarchy. Use inheritance to flow this to all descendants. Then add inheritance breaks and explicit ACEs only where needed for stricter or different access. This approach minimizes the number of unique ACLs while maintaining precise control.

Windows Inheritance Deep Dive

Windows implements sophisticated ACE inheritance with fine-grained control over how each entry propagates. Understanding these mechanics is essential for enterprise permission design.

The Inheritance Flag Matrix:

Every Windows ACE has up to four inheritance flags that control its propagation behavior:

Windows ACE Inheritance Flags Detailed
Flag	Constant	icacls	Meaning
Object Inherit	OBJECT_INHERIT_ACE	(OI)	Children that are FILES inherit this ACE
Container Inherit	CONTAINER_INHERIT_ACE	(CI)	Children that are DIRECTORIES inherit this ACE
No Propagate	NO_PROPAGATE_INHERIT_ACE	(NP)	Inheritance stops at immediate children
Inherit Only	INHERIT_ONLY_ACE	(IO)	ACE doesn't apply to this object, only to children

Inheritance Flag Combinations Explained
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
# Full inheritance (most common)
(OI)(CI)
# - Applies to this folder
# - Inherited by all subfolders (recursive)
# - Inherited by all files (recursive)
# - Subfolders continue to propagate to their children
 
# Files only
(OI)
# - Applies to this folder
# - Inherited by files in this folder and all subfolders
# - NOT inherited by subfolders themselves
 
# Directories only  
(CI)
# - Applies to this folder
# - Inherited by subfolders (recursive)
# - NOT inherited by files
 
# This folder and immediate children only
(OI)(CI)(NP)
# - Applies to this folder
# - Inherited by immediate child files
# - Inherited by immediate child folders
# - NOT propagated to grandchildren (NP stops it)
 
# Children only, not this folder
(OI)(CI)(IO)
# - Does NOT apply to this folder
# - Inherited by all child files and folders (recursive)
# - Useful for CREATOR OWNER patterns
 
# Immediate children only, not this folder
(OI)(CI)(IO)(NP)  or  (NP)(IO)
# - Does NOT apply to this folder
# - Inherited by immediate children only
# - Stops at direct descendants
 
# Files only in immediate children
(OI)(NP)
# - Applies to this folder
# - Inherited only by files in THIS folder
# - Not inherited by files in subfolders (NP stops traverse)
 
# Files only, not self (for child files)
(OI)(IO)
# - Does NOT apply to this folder
# - Inherited only by files (all levels)
# - Not applied to directories
 
# Visual: What each flag combination produces
#
#   /Parent (source ACE here)
#   ├── file1.txt          (OI) or (OI)(CI) = inherits
#   ├── file2.txt          (OI) or (OI)(CI) = inherits
#   ├── /SubDir           (CI) or (OI)(CI) = inherits
#   │   ├── file3.txt     (OI) or (OI)(CI) without (NP) = inherits
#   │   └── /Deep         (CI) or (OI)(CI) without (NP) = inherits
#   └── file4.txt

Inheritance Propagation Process:

When a new object is created in Windows, the system performs the following steps to determine its ACL:

Windows Inheritance Algorithm (Pseudocode)
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
def compute_inherited_acl(parent, new_object, explicit_aces, is_container):
    """
    Computes the complete ACL for a newly created object.
    """
    final_dacl = []
    
    # Step 1: Add explicit ACEs first (in canonical order)
    explicit_deny = [a for a in explicit_aces if a.type == DENY]
    explicit_allow = [a for a in explicit_aces if a.type == ALLOW]
    final_dacl.extend(sort_deny_first(explicit_deny))
    final_dacl.extend(explicit_allow)
    
    # Step 2: Process each ACE in parent's DACL
    for parent_ace in parent.dacl:
        inherited_ace = None
        
        # Check if this ACE should be inherited
        if is_container:
            # Directory: Check CONTAINER_INHERIT flag
            if not (parent_ace.flags & CONTAINER_INHERIT_ACE):
                continue  # Skip - not inherited by containers
        else:
            # File: Check OBJECT_INHERIT flag
            if not (parent_ace.flags & OBJECT_INHERIT_ACE):
                continue  # Skip - not inherited by objects
        
        # Create inherited copy
        inherited_ace = copy(parent_ace)
        inherited_ace.flags |= INHERITED_ACE  # Mark as inherited
        
        # Handle INHERIT_ONLY - remove it for the child
        inherited_ace.flags &= ~INHERIT_ONLY_ACE
        
        # Handle NO_PROPAGATE - clear inheritance flags for grandchildren
        if parent_ace.flags & NO_PROPAGATE_INHERIT_ACE:
            inherited_ace.flags &= ~(OBJECT_INHERIT_ACE | 
                                     CONTAINER_INHERIT_ACE |
                                     NO_PROPAGATE_INHERIT_ACE)
        
        # Handle special trustee substitution
        inherited_ace.sid = substitute_special_trustees(
            parent_ace.sid, 
            creator_user_sid,
            creator_group_sid
        )
        
        final_dacl.append(inherited_ace)
    
    # Step 3: Apply to new object
    new_object.dacl = final_dacl
    return new_object
 
 
def substitute_special_trustees(original_sid, creator, creator_group):
    """Replace special SIDs at inheritance time."""
    if original_sid == CREATOR_OWNER_SID:
        return creator
    elif original_sid == CREATOR_GROUP_SID:
        return creator_group
    else:
        return original_sid

INHERITED_ACE Flag

When an ACE is inherited, Windows sets the INHERITED_ACE (I) flag. This flag is informational—it tells you the ACE came from a parent. In icacls output, inherited ACEs show (I) in their flags. This distinction between explicit and inherited ACEs is crucial for understanding which permissions you can modify locally versus which come from above.

POSIX Default ACL Inheritance

POSIX inheritance works fundamentally differently from Windows. Instead of flags on individual entries, POSIX uses a separate default ACL on directories that specifies what access ACL new children should receive.

Key POSIX Inheritance Characteristics:

POSIX Default ACL Behavior

•Only directories can have default ACLs (they have no meaning for files)
•The default ACL is a template for new children's access ACLs
•New files get access ACL derived from parent's default ACL
•New directories get access ACL derived from parent's default ACL PLUS a copy of the default ACL itself
•Changing a parent's default ACL does NOT affect existing children
•There is no concept of 'inherited' entries—all entries on a file are equivalent

POSIX Inheritance Mechanics
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
# Set up a directory hierarchy with default ACLs
 
# Create root project directory
$ mkdir /project
$ chown manager:devteam /project
 
# Set access ACL for the directory itself
$ setfacl -m u::rwx,g::rwx,u:auditor:rx,g:ops:rx,o::---,m::rwx /project
 
# Set default ACL (template for new children)
$ setfacl -d -m u::rwx,g::rwx,u:auditor:rx,g:ops:rx,o::---,m::rwx /project
 
# Verify both ACLs
$ getfacl /project
# file: project
# owner: manager
# group: devteam
user::rwx                 # Access ACL
user:auditor:r-x          #
group::rwx                #
group:ops:r-x             #
mask::rwx                 #
other::---                #
default:user::rwx         # Default ACL (template)
default:user:auditor:r-x  #
default:group::rwx        #
default:group:ops:r-x     #
default:mask::rwx         #
default:other::---        #
 
# Create a file - inherits access ACL from default ACL
$ touch /project/code.py
$ getfacl /project/code.py
# file: project/code.py
# owner: manager
# group: devteam
user::rw-                 # Execute removed for files
user:auditor:r--          # Execute removed (it's a file, not dir)
group::rw-                #effective:rw-
group:ops:r--             #effective:r--
mask::rw-                 # Mask computed from requested mode
other::---
 
# Create a subdirectory - inherits BOTH access ACL and default ACL
$ mkdir /project/src
$ getfacl /project/src
# file: project/src
# owner: manager
# group: devteam
user::rwx                 # Access ACL (from parent's default)
user:auditor:r-x          #
group::rwx                #
group:ops:r-x             #
mask::rwx                 #
other::---                #
default:user::rwx         # Default ACL (copied from parent's default)
default:user:auditor:r-x  # This enables recursive inheritance!
default:group::rwx        #
default:group:ops:r-x     #
default:mask::rwx         #
default:other::---        #
 
# Now /project/src/subdir will also inherit because src has default ACL
$ mkdir /project/src/subdir
$ touch /project/src/subdir/file.txt
# Both inherit from /project/src's default ACL

POSIX Inheritance is Snapshot-based

When you change a parent's default ACL in POSIX, existing children are NOT updated. They retain the ACL they received at creation time. To apply new defaults to existing files, you must recursively update them with setfacl -R. This is fundamentally different from Windows where inherited ACEs can be updated by modifying the parent.

POSIX: Updating ACLs Recursively
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
# Scenario: Need to add a new team member to existing hierarchy
 
# This ONLY affects future files:
$ setfacl -d -m u:newuser:rx /project
 
# Existing files don't see the change!
$ getfacl /project/code.py  # No newuser entry!
 
# To update existing files, use recursive setfacl:
$ setfacl -R -m u:newuser:rx /project
 
# To update default ACLs on all subdirectories recursively:
$ setfacl -R -d -m u:newuser:rx /project
 
# Complete update: access ACL everywhere + default ACL on directories
$ find /project -type d -exec setfacl -d -m u:newuser:rx {} \;
$ find /project -exec setfacl -m u:newuser:rx {} \;
 
# Or use setfacl's native recursive:
$ setfacl -Rm u:newuser:rx /project
$ setfacl -Rdm u:newuser:rx /project

Breaking and Protecting Inheritance

Sometimes you need to prevent inheritance from propagating to specific objects or entire subtrees. Both POSIX and Windows provide mechanisms for this, though they work quite differently.

Windows Inheritance Protection
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
# Windows provides fine-grained inheritance control:
 
# Method 1: Disable inheritance, REMOVE inherited ACEs
# The object becomes completely independent
C:\> icacls "C:\Data\Confidential" /inheritance:r
# /inheritance:r = remove inherited ACEs
 
# Method 2: Disable inheritance, CONVERT inherited ACEs to explicit
# Inherited ACEs become explicit, under your control
C:\> icacls "C:\Data\Confidential" /inheritance:d
# /inheritance:d = disable inheritance but copy ACEs
 
# Method 3: Re-enable inheritance from parent
C:\> icacls "C:\Data\Confidential" /inheritance:e
# /inheritance:e = enable inheritance
 
# Method 4: Reset - remove explicit ACEs, enable inheritance
C:\> icacls "C:\Data\Confidential" /reset
# Clears all explicit ACEs and re-inherits from parent
 
# Using PowerShell for more control:
$acl = Get-Acl "C:\Data\Confidential"
 
# Check current protection state
$acl.AreAccessRulesProtected  # True = inheritance disabled
 
# Disable inheritance, keep existing rules
$acl.SetAccessRuleProtection($true, $true)
# First param: $true = protected (no inheritance)
# Second param: $true = preserve existing inherited as explicit
 
# Disable inheritance, remove inherited rules
$acl.SetAccessRuleProtection($true, $false)
# Second param: $false = remove inherited ACEs
 
# Re-enable inheritance
$acl.SetAccessRuleProtection($false, $false)
 
# Apply changes
Set-Acl "C:\Data\Confidential" $acl
 
# Real-world example: Create a protected confidential folder
mkdir "C:\Data\Confidential"
 
# Remove all inheritance
icacls "C:\Data\Confidential" /inheritance:r
 
# Set explicit permissions (no inheritance markers)
icacls "C:\Data\Confidential" /grant:r "NT AUTHORITY\SYSTEM:(OI)(CI)F"
icacls "C:\Data\Confidential" /grant:r "BUILTIN\Administrators:(OI)(CI)F"
icacls "C:\Data\Confidential" /grant:r "CONTOSO\Executives:(OI)(CI)M"
 
# Verify - no (I) markers on ACEs
icacls "C:\Data\Confidential"
# C:\Data\Confidential
#   NT AUTHORITY\SYSTEM:(OI)(CI)(F)
#   BUILTIN\Administrators:(OI)(CI)(F)  
#   CONTOSO\Executives:(OI)(CI)(M)
# Note: No (I) prefix - these are explicit ACEs

When to Break Inheritance

Break inheritance when: 1) A subtree needs significantly different access than the parent, 2) Adding an explicit deny would conflict with inherited allows, 3) Compliance requires demonstrably isolated access control, 4) Performance optimization requires smaller ACLs. Don't break inheritance just because one user needs different access—use explicit ACEs for exceptions.

Multi-Level Inheritance Hierarchies

Enterprise environments often require complex permission hierarchies with multiple inheritance points. Understanding how inheritance accumulates and interacts across levels is crucial for correct design.

Accumulative Inheritance in Windows:

In Windows, child objects can accumulate ACEs from multiple ancestors. Each inheritable ACE from each ancestor is independently evaluated:

Multi-Level Windows Inheritance
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
# Enterprise hierarchy example:
#
# C:\Corporate
# ├── Departments
# │   ├── Engineering
# │   │   ├── Projects
# │   │   │   ├── Alpha
# │   │   │   │   └── secret.doc
# │   │   │   └── Beta
# │   │   └── Shared
# │   └── Sales
# └── Shared
 
# Set up inheritance at each level:
 
# Level 0: Corporate - Everyone can read
icacls "C:\Corporate" /inheritance:r
icacls "C:\Corporate" /grant "BUILTIN\Administrators:(OI)(CI)F"
icacls "C:\Corporate" /grant "NT AUTHORITY\SYSTEM:(OI)(CI)F"
icacls "C:\Corporate" /grant "CONTOSO\All Staff:(OI)(CI)R"
 
# Level 1: Departments (inherits from Corporate)
# Engineering department gets modify
icacls "C:\Corporate\Departments\Engineering" \
    /grant "CONTOSO\Engineering:(OI)(CI)M"
 
# Level 2: Projects (inherits from Engineering and Corporate)
# Project Managers get full control
icacls "C:\Corporate\Departments\Engineering\Projects" \
    /grant "CONTOSO\Project Managers:(OI)(CI)F"
 
# Level 3: Alpha (inherits from all ancestors)
# Alpha team gets special access
icacls "C:\Corporate\Departments\Engineering\Projects\Alpha" \
    /grant "CONTOSO\Alpha Team:(OI)(CI)M"
 
# Now let's see what secret.doc inherits:
icacls "C:\Corporate\Departments\Engineering\Projects\Alpha\secret.doc"
# secret.doc
#   BUILTIN\Administrators:(I)(F)         # From C:\Corporate
#   NT AUTHORITY\SYSTEM:(I)(F)            # From C:\Corporate
#   CONTOSO\All Staff:(I)(R)              # From C:\Corporate  
#   CONTOSO\Engineering:(I)(M)            # From Engineering
#   CONTOSO\Project Managers:(I)(F)       # From Projects
#   CONTOSO\Alpha Team:(I)(M)             # From Alpha
 
# The file has SIX inherited ACEs from four ancestors!
# Access evaluation checks ALL of them.
 
# Who can access secret.doc?
# - All Staff: Read
# - Engineering (if not in Alpha Team): Modify (supersets Read)
# - Project Managers: Full Control
# - Alpha Team: Modify
# - Administrators/SYSTEM: Full Control

POSIX Multi-Level Inheritance:

POSIX inheritance doesn't accumulate in the same way. Each directory's default ACL is independent—it's copied from the parent at creation time but modifications to ancestors don't propagate:

Multi-Level POSIX Inheritance
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
# Same hierarchy in POSIX:
#
# /corporate
# ├── departments
# │   ├── engineering
# │   │   └── projects
# │   │       └── alpha
# │   │           └── secret.txt
# │   └── sales
# └── shared
 
# Set up each level with default ACLs:
 
# Level 0: Corporate
setfacl -m u::rwx,g::r-x,g:staff:rx,o::--- /corporate
setfacl -d -m u::rwx,g::r-x,g:staff:rx,o::--- /corporate
 
# Level 1: Departments/Engineering  
# Created normally, inherits from /corporate's default ACL
mkdir /corporate/departments
mkdir /corporate/departments/engineering
# Both get: u::rwx,g::r-x,g:staff:rx,o::---
 
# Now ADD engineering group to engineering's default ACL
setfacl -m g:engineering:rwx /corporate/departments/engineering
setfacl -d -m g:engineering:rwx /corporate/departments/engineering
 
# Level 2: Projects
mkdir /corporate/departments/engineering/projects
setfacl -m g:projectmgrs:rwx /corporate/departments/engineering/projects
setfacl -d -m g:projectmgrs:rwx /corporate/departments/engineering/projects
 
# Level 3: Alpha
mkdir /corporate/departments/engineering/projects/alpha  
setfacl -m g:alphateam:rwx /corporate/departments/engineering/projects/alpha
setfacl -d -m g:alphateam:rwx /corporate/departments/engineering/projects/alpha
 
# Create the file
touch /corporate/departments/engineering/projects/alpha/secret.txt
 
# What does secret.txt have?
getfacl /corporate/departments/engineering/projects/alpha/secret.txt
# file: corporate/departments/engineering/projects/alpha/secret.txt
# owner: user
# group: group
user::rw-
group::rwx               #effective:rw-
group:alphateam:rwx      #effective:rw-
group:projectmgrs:rwx    #effective:rw-  (IF added to alpha's default)
group:engineering:rwx    #effective:rw-  (IF propagated)
group:staff:r-x          #effective:r--  (IF propagated)
mask::rw-
other::---
 
# KEY INSIGHT: In POSIX, you must explicitly include ALL groups
# you want in EACH directory's default ACL.
# They don't automatically accumulate from ancestors!
 
# If you only set g:alphateam on /alpha's default, that's all files get.
# Parent's groups aren't automatically included.

POSIX Inheritance Isolation

A crucial difference: In POSIX, each directory's default ACL is self-contained. If you want groups from multiple levels to have access to deeply nested files, you must include all of them in every intermediate directory's default ACL. They don't automatically 'stack' as Windows inherited ACEs do. This makes POSIX simpler but requires more manual configuration for complex hierarchies.

Inheritance Design Patterns

Experienced administrators use proven design patterns for structuring inheritance. Here are the most effective patterns with their use cases:

Pattern 1: Hierarchical Access (Cone Model)

Each level adds more restrictive access while inheriting parent access. Access expands as you go UP the hierarchy, restricts as you go DOWN.

Pattern 1: Hierarchical Access
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# Structure:
#   /company          (All Staff: R)
#   ├── /department   (All Staff: R, Dept: RW)
#   │   ├── /team     (All Staff: R, Dept: RW, Team: Full)
#   │   │   └── /personal (Team: Full, Individual: Full - protected)
 
# Implementation (Windows):
icacls "C:\Company" /grant "All Staff:(OI)(CI)R"
icacls "C:\Company\Engineering" /grant "Engineering:(OI)(CI)M"
icacls "C:\Company\Engineering\TeamA" /grant "TeamA:(OI)(CI)F"
 
# Personal folders break inheritance
icacls "C:\Company\Engineering\TeamA\Alice" /inheritance:r
icacls "C:\Company\Engineering\TeamA\Alice" /grant "Alice:(OI)(CI)F"
icacls "C:\Company\Engineering\TeamA\Alice" /grant "SYSTEM:(OI)(CI)F"
 
# Use case: Corporate file servers, department shares

Pattern 2: Role-Based Layers

Different permission sets at each layer, with selective inheritance to appropriate object types.

Pattern 2: Role-Based Layers
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
# Structure:
#   /application
#   ├── /config       (Admins: Full, App: R - protected)
#   ├── /data         (Admins: Full, App: RW - inherits to files only)
#   ├── /logs         (Admins: Full, App: WriteOnly - audit)
#   └── /temp         (Admins: Full, App: Full, Auto-delete)
 
# Config: Admin manages, app reads
icacls "C:\App\Config" /inheritance:r
icacls "C:\App\Config" /grant "SYSTEM:(OI)(CI)F"
icacls "C:\App\Config" /grant "Administrators:(OI)(CI)F"
icacls "C:\App\Config" /grant "AppServiceAccount:(OI)(CI)R"
 
# Data: App can modify files, dirs inherit different permissions
icacls "C:\App\Data" /inheritance:r
icacls "C:\App\Data" /grant "AppServiceAccount:(CI)(WD,AD)"  # Create dirs
icacls "C:\App\Data" /grant "AppServiceAccount:(OI)M"        # Modify files
 
# Logs: Append only (write but not read own logs - security)
icacls "C:\App\Logs" /inheritance:r  
icacls "C:\App\Logs" /grant "AppServiceAccount:(OI)W"
icacls "C:\App\Logs" /deny "AppServiceAccount:(OI)RD"  # Can't read back
 
# Use case: Application deployment, service accounts

Pattern 3: Protected Zones with Bridges

Mostly protected subtrees with specific "bridge" directories that allow controlled access between zones.

Pattern 3: Protected Zones
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
# Structure:
#   /data
#   ├── /zone-a       (Protected - TeamA only)
#   │   ├── /private  (TeamA only, no inheritance)
#   │   └── /share-out (TeamA write, Others read - bridge)
#   ├── /zone-b       (Protected - TeamB only)
#   │   ├── /private  
#   │   └── /share-out
#   └── /common       (All teams RW - meeting point)
 
# Zone A: Protected
icacls "C:\Data\ZoneA" /inheritance:r
icacls "C:\Data\ZoneA" /grant "TeamA:(OI)(CI)F"
icacls "C:\Data\ZoneA" /grant "SYSTEM:(OI)(CI)F"
 
# Zone A Share-Out: Bridge point
icacls "C:\Data\ZoneA\ShareOut" /grant "All Staff:(OI)(CI)R"
# TeamA still has full control (inherited from ZoneA)
# Others can only read from ShareOut
 
# Common: Everyone can collaborate
icacls "C:\Data\Common" /inheritance:r
icacls "C:\Data\Common" /grant "All Staff:(OI)(CI)M"
 
# Use case: Multi-tenant systems, compliance boundaries

Pattern Selection Guide

Use Hierarchical Access when organizational structure maps to access needs. Use Role-Based Layers when different parts of an application need different access types. Use Protected Zones when security boundaries are paramount and cross-zone access should be auditable via specific bridge points.

Troubleshooting Inheritance Issues

Inheritance problems are among the most confusing permission issues to diagnose. Here's a systematic approach to debugging inheritance:

Windows Inheritance Troubleshooting
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
# Symptom: File doesn't have expected inherited permissions
 
# Step 1: Check if inheritance is enabled on the problematic file
C:\> icacls "C:\Path\To\File.txt"
# Look for (I) markers on ACEs
# If NO (I) markers, inheritance is disabled or was never applied
 
# Step 2: Check parent's inheritable ACEs
C:\> icacls "C:\Path\To"
# Look for (OI) and/or (CI) on parent's ACEs
# If the user's ACE has (OI), files should inherit
# If the user's ACE has (CI), directories should inherit
 
# Step 3: Trace up the chain
C:\> icacls "C:\Path"
C:\> icacls "C:\"
# Find where the expected ACE originates
# Check for (NP) which stops propagation
 
# Step 4: Check for protection points
# Look for objects that have NO (I) entries - they're protected
 
# Step 5: Look for inheritance ONLY entries
# An ACE with (IO) applies ONLY to children, not the current object
# If user has (OI)(CI)(IO) on /Path, they can't access /Path itself
 
# Step 6: Check for deny entries blocking access
C:\> icacls "C:\Path\To\File.txt" | findstr DENY
# Deny ACEs are evaluated first and override allows
 
# Step 7: Verify group membership
C:\> whoami /groups
# Ensure the user is actually in the groups that have access
 
# Step 8: Use Effective Access tab (GUI) or PowerShell
$path = "C:\Path\To\File.txt"
$user = "CONTOSO\username"
$acl = Get-Acl $path
$rules = $acl.Access | Where-Object { 
    $_.IdentityReference -eq $user -or 
    $_.IdentityReference -eq "Everyone"
}
$rules | Format-Table IdentityReference, FileSystemRights, AccessControlType, IsInherited
 
# Step 9: Fix by resetting inheritance
C:\> icacls "C:\Path\To\File.txt" /reset
# This removes explicit ACEs and re-applies inheritance from parent

POSIX Inheritance Troubleshooting
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
# Symptom: New files don't have expected ACL entries
 
# Step 1: Check if parent has default ACL
$ getfacl /path/to/parent/
# Look for "default:" entries
# If no default entries, umask applies instead of inheritance
 
# Step 2: Verify default ACL has the expected entries
$ getfacl -d /path/to/parent/
# Shows ONLY the default ACL
# Verify your user/group is listed with correct permissions
 
# Step 3: Check existing file was created AFTER default ACL was set
$ stat /path/to/parent/file.txt
# Compare modification times
# Files created BEFORE default ACL was set won't have it!
 
# Step 4: Check the mask
$ getfacl /path/to/parent/file.txt
# Look for "#effective:" comments
# If permissions are limited, check mask value
# mask::r-- will limit named entries to read-only
 
# Step 5: Verify intermediate directories have default ACLs
$ getfacl -d /path/
$ getfacl -d /path/to/
$ getfacl -d /path/to/parent/
# Each must have default ACL for continuous inheritance
 
# Step 6: Check requested mode intersection
# If application created file with mode 0600, mask will be ---
# for group/other, effectively denying access
$ strace -e trace=openat touch /path/to/parent/test.txt 2>&1 | grep openat
# See what mode the application requested
 
# Step 7: Fix: Apply ACL recursively
$ setfacl -R -m u:username:rw /path/to/parent/
# Updates all existing files
 
$ setfacl -R -d -m u:username:rw /path/to/parent/
# Updates default ACL on all directories for future files

Common Root Causes

Protection: Object or ancestor has inheritance disabled. 2) Wrong flags: Parent ACE has (CI) but object is a file (needs (OI)). 3) Inherit-only: Parent ACE has (IO) so it doesn't apply to parent itself. 4) No propagate: Ancestor has (NP) stopping inheritance. 5) POSIX timing: Default ACL was set after files were created.

Summary: Mastering ACL Inheritance

ACL inheritance is a powerful mechanism that enables scalable permission management across complex hierarchies. Mastering inheritance mechanics allows you to design maintainable, secure permission structures. Let's consolidate the key concepts:

Key Takeaways

•Windows uses per-ACE flags — (OI), (CI), (IO), (NP) control exactly how each entry propagates through the hierarchy.
•POSIX uses default ACLs — Separate template ACLs on directories that new children copy at creation time.
•Windows inheritance is dynamic — Changes to parent ACEs can affect existing children (unless protected).
•POSIX inheritance is snapshot-based — Existing children are never affected by changes to parent's default ACL.
•Protection points break inheritance chains — Use judiciously to create security boundaries.
•Design patterns provide proven structures — Hierarchical, role-based, and protected zones solve common requirements.

What's Next:

Now that you understand inheritance deeply, we'll explore ACL performance in the next page. You'll learn how ACL size affects access check speed, storage implications, and optimization strategies for high-performance systems.

Page Complete

You now have expert-level knowledge of ACL inheritance in both Windows and POSIX systems. You can design multi-level hierarchies, control inheritance propagation, break inheritance when needed, and troubleshoot complex inheritance issues. Next, we'll explore performance considerations for ACL-heavy systems.