@@ -16,16 +16,9 @@ const (
1616 // WindowsACLRevokeCapability removes any existing ACE (allow or deny) for
1717 // Capability at Path, without itself granting or denying anything (applied
1818 // via SetEntriesInAclW's SET_ACCESS mode with a zero mask, not
19- // REVOKE_ACCESS — see windowsACLAccess for why). It reconciles stale
20- // shared/descendant DenyWrite ACEs an earlier setup run applied for the
21- // stable read-only capability SID (see BuildWindowsACLPlan) that a later
22- // run no longer intends: if a path previously covered by the
23- // shared-root/descendant DenyWrite mitigation is later configured as an
24- // allowed write root, that old deny is otherwise left on disk and wins
25- // over the new Allow under Windows' deny-before-allow evaluation — see
26- // jatmn's review. Clearing a SID with no matching ACE is a safe no-op, so
27- // this can always be emitted unconditionally alongside every write-root
28- // Allow entry.
19+ // REVOKE_ACCESS — see windowsACLAccess for why). It is consumed by
20+ // applyWindowsACLPlan for migration cleanup and tests; no current
21+ // plan-generation path emits this action, preserving legacy-process confinement.
2922 WindowsACLRevokeCapability WindowsACLAction = "revoke-capability"
3023)
3124
@@ -44,33 +37,15 @@ type WindowsACLEntry struct {
4437 Materialize bool `json:"materialize,omitempty"`
4538 // ScanDescendants marks a shared-root DenyWrite entry whose EXISTING
4639 // writable descendants must ALSO be denied, one direct (non-inheriting)
47- // deny per writable descendant, at apply time. A non-inherited deny on the
48- // root object alone does not cover a pre-existing child that independently
49- // grants Users/Authenticated Users write, because a Windows access check
50- // for that child never consults a non-inherited ACE on its parent. This is
51- // deliberately NOT serialized (json:"-"): the concrete descendant set is
52- // live-filesystem state that differs between the setup process and a later
53- // command run, so folding it into the hashed plan would make
54- // ValidateWindowsSandboxSetupMarker non-deterministic. The flag itself is
55- // derived deterministically from the same inputs on both sides, and the
56- // descendant enumeration/denies happen as an apply-time side effect in
57- // applyWindowsACLPlan (windows-only), never in the cross-platform plan hash.
40+ // deny per writable descendant, at apply time. This flag and its associated
41+ // walker are consumed by applyWindowsACLPlan and tests; no current
42+ // plan-generation path sets this flag since broad shared-root DenyWrite ACEs
43+ // and SID broadening are no longer planned.
5844 ScanDescendants bool `json:"-"`
59- // RevokeDescendants marks a write-root's WindowsACLRevokeCapability entry
60- // (see the constant below) as needing the same stale-deny cleanup applied
61- // recursively to the root's existing descendants, not just the root path
62- // itself. A tree scanned and denied by an earlier setup run (either
63- // because it WAS one of the four shared roots, or because it was a
64- // writable descendant applyWindowsSharedDescendantDenies found and denied
65- // elsewhere in the tree) can later be promoted to an allowed write root by
66- // the caller configuring some ANCESTOR of it as a WriteRoot. Revoking only
67- // at the exact configured root leaves any stale direct, non-inheriting
68- // deny on that ancestor's descendants in place, and a stale deny wins over
69- // the newly-added inheritable Allow under Windows' deny-before-allow
70- // evaluation — see jatmn's review. Like ScanDescendants, this is
71- // deliberately NOT serialized (json:"-"): the concrete stale-deny set is
72- // live-filesystem state, and the actual descendant walk/revoke happens as
73- // an apply-time side effect in applyWindowsACLPlan (windows-only).
45+ // RevokeDescendants marks a WindowsACLRevokeCapability entry as needing
46+ // stale-deny cleanup applied recursively to existing descendants, not just
47+ // the root path itself. This flag is consumed by applyWindowsACLPlan for
48+ // migration cleanup and tests; no current plan-generation path sets this flag.
7449 RevokeDescendants bool `json:"-"`
7550}
7651
0 commit comments