[Windows sandbox] Low integrity label does not propagate to pre-existing subdirectories, so workspace-write works only at the workspace root

[Saretheya]

Summary

On Windows, after upgrading to 0.2.0-rc.2, every directory that already existed inside a
workspace becomes read-only to confined commands, while the workspace root stays
writable and newly created directories are fine.

PS> New-Item -ItemType Directory -Path 'D:\DSH工作区\临时文件\_probe'
New-Item : Access to the path 'D:\DSH工作区\临时文件\_probe' is denied.

The cause is that the workspace-root Low integrity label is inheritable for future
objects only — Windows does not retroactively apply it to existing children. Because
grantWrite then short-circuits on its exact-triple check, the propagation is skipped
forever, so the inconsistency never self-heals.

Environment

• DSH 0.2.0-rc.2, profile web, policy workspace-write
• Windows 11, NTFS, workspaces on D:\
• Workspaces that predate the upgrade (directories created 2026-08 … 2026-10-03)

Root cause

dsh-sandbox-windows-acl lowers the confined token to Low integrity
(lib/types-*.js:1291 restrictTokenIntegrity) and marks the workspace root with an
inheritable no-write-up label (buildLowLabelAcl, :425-442), applied together with the
DACL in one SetNamedSecurityInfoW(..., DACL|LABEL) call (:485).

The kernel then refuses write-class access from the Low token to any object not labelled
Low. Since the label's (OI)(CI) inheritance only affects objects created after it is
applied, pre-existing subdirectories stay unlabelled (= Medium) and become unwritable.

Re-provisioning does not fix it, because grantWrite skips the SetNamedSecurityInfoW
call when the exact triple is already present:

// lib/types-*.js:595
if (oldAcl !== null && labelAcl !== null && hasExactGrant(oldAcl, sidPtr)
    && hasExactDeny(oldAcl, worldSidPtr) && hasExactLabel(labelAcl, lowLabelSidPtr)) {
  return;   // <- tree-wide propagation skipped; old children stay unlabelled
}

hasExactLabel only inspects the root's SACL, so the root satisfies the skip while its
existing descendants remain unlabelled. On this machine the root had all three elements
from an earlier provisioning, so no later run ever relabelled the tree.

Evidence

object	created	Low label	write from confined pwsh
workspace root D:\DSH工作区	—	yes (I)(OI)(CI)(NW)	OK
…\资产, …\记忆	2026-08-26	none	denied
…\归档, …\发布	2026-09-15	none	denied
…\临时文件, …\.pnpm-store	2026-10-02	none	denied
…\_dshprobe	2026-10-16 (after upgrade)	yes	OK

• Confined token: whoami /groups → Mandatory Label\Low Mandatory Level S-1-16-4096
  (SeChangeNotifyPrivilege only).
• The pre-existing dirs have ample DACL rights (user FA, Authenticated Users M,
  capability SID (W,D,DC)) — so this is the integrity check, not a DACL denial.
• Reads succeed, writes fail — the signature of no-write-up.

Impact

Any workspace that existed before the upgrade is permanently inconsistent: agents can write
at the workspace root but not into any pre-existing subdirectory. In practice this makes
workspace-write unusable for real work, because a workspace's useful content lives in
subdirectories.

Suggested fix

When provisioning, after the root's grant, walk the workspace once and apply the Low label
to every descendant that lacks it, skipping reparse points (see the /T issue below).
The exact-ACE/exact-label skip could then be narrowed: it currently treats "root is
correct" as "tree is correct", which is what makes the state permanent.

At minimum, please document the limitation — "upgrading leaves pre-existing workspaces with
unwritable subdirectories; run X to repair" — since the symptom (workspace root writable,
subdirectories denied) is easy to misattribute to user ACL damage.

---

Related: icacls /T in a repair script crosses junctions

Not a DSH bug per se, but worth warning about, because it is the obvious way to repair the
state above and it silently writes outside the workspace.

icacls <dir> /setintegritylevel (OI)(CI)L /T /C descends through junctions and labels
their targets. Controlled repro (link on D:, target on C:):

junction: src\sub\node_modules\linked-pkg -> C:\...\pentarget
after:  TARGET root = NONE   TARGET child = LOW   TARGET grandchild = LOW
VERDICT: PENETRATED

On this machine the workspace tree contained 1576 junctions pointing outside (an npm
install tree and a plugin tree), so running such a repair labelled 31718 objects outside
the workspace. All were reverted, and no file contents were touched
(icacls /setintegritylevel only edits the SACL) — but a repair tool that follows links
can write outside the sandbox boundary it is supposed to enforce.

Note that icacls <dir> /grant ... (without /T) does not follow links — the
inheritable ACE propagates by normal inheritance, which stops at the junction. So: grant
without /T, and label with a self-recursive walk that skips reparse points.

Related: the repair must apply all three parts, or it opens a cross-workspace delete hole

grantWrite applies three things together (:608):

Buffer.concat([
  buildExplicitAccess(worldSidPtr, 3, 64, 2),   // Everyone:(CI)(DENY)(FILE_DELETE_CHILD)
  buildExplicitAccess(sidPtr, 1, GRANT_MASK),   // capability SID allow
]), oldAcl, { kind: 'apply', acl: lowLabelAcl } // Low label

A hand-rolled repair that applies only the Low label (my first attempt) produces a real
privilege issue: FILE_DELETE_CHILD is evaluated on the parent directory and, as your
own README notes, does not require a restricting-SID countersignature. With the target
labelled Low (so the integrity check passes) and D:\ granting Modify to
Authenticated Users, a session confined to workspace A could then delete objects in
workspace B without approval — verified:

session workspace = A (Low token)
B\memory\xw-target.md   .NET File.Delete = SUCCESS   (before the deny was added)
after adding Everyone:(CI)(DENY)(FILE_DELETE_CHILD) to B's root:
B\memory\xw-target.md   .NET File.Delete = ACCESS DENIED   (all 6 workspaces, all paths)

Deleting is the sharp edge; the same path also allowed removing whole directory trees.
Since the fix is a one-line ACE, it may be worth exposing a documented "repair recipe" that
includes all three parts, so people repairing the label issue don't accidentally widen
cross-workspace access.

[argszero]

Thank you — this is the most complete measurement of this shape so far, and your two "Related" sections answer questions the earlier reports left open. It is also the fourth report of it, and nothing in the source has moved between them, so the honest framing is "chronic and unfixed" rather than "new".

The same shape, three times before yours

thread	date	what it measured
#8383	2026-09-30	label missing on children while the DACL arrives — your case, one month earlier
#8421	2026-09-30	the same shape isolated to the label half
#9559	2026-10-13	the same on a pre-existing project tree, with one child carrying neither the ACE nor the label
#423	2026-08-13	the ACE half of the same union, from before the label layer existed

We replied on each of the first three. The timeline is the part worth knowing: the Low-label layer landed 2026-09-19 (d5ad3baeb5, "fix(sandbox): confine Windows deletes with a Low integrity label"), and the exact skip block you quote was last touched in that same wave (36e632751e, 2026-09-19). Between the first report and yours the file has not changed, so the reports of 09-30, 10-13 and 10-16 all describe one unchanged predicate.

Your source reading, checked against the source rather than the bundle

Every line you cite is accurate. Here is the same code at head (1517a4dbca), which is easier to patch than lib/types-*.js:

• buildLowLabelAcl → packages/sandbox/sandbox-windows-acl/src/acl.ts:169-188; the inheritance flag is SUB_CONTAINERS_AND_OBJECTS_INHERIT (:181) and the policy SYSTEM_MANDATORY_LABEL_NO_WRITE_UP — your (OI)(CI)(NW).
• the single call carrying DACL and label → mergeAndApply, src/acl.ts:255-259 (DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION).
• the skip → grantWrite, src/acl.ts:386-395. Your rendering is faithful, guard included.
• the three edits → src/acl.ts:405-412. Your constants decode as DENY_ACCESS = 3, FILE_DELETE_CHILD = 0x40, CONTAINER_INHERIT_ACE = 0x2, GRANT_ACCESS = 1 (src/win32-abi.ts:22, :81, :83, :89). GRANT_MASK is (FILE_GENERIC_WRITE | DELETE | FILE_DELETE_CHILD) & ~STANDARD_RIGHTS_WRITE (:28) — which is why your (W,D,DC) read of a child's ACE is exactly the capability ACE and not a coincidence.
• restrictTokenIntegrity → src/token.ts:156-165.

The permanence has two halves and you found both:

1. Nothing below the root is ever named. The backend enumerates the workspace root and the session's private temp directory and nothing else — packages/sandbox/sandbox-local/src/index.ts:409 (the standing grant.add(workspaceRoot, true)) and :431 (the revocable temp grant), with no directory walk anywhere in acl.ts, grant.ts or index.ts.
2. The skip keys on the root. Once the root satisfies all three, every later provision returns before touching anything, so the tree is never revisited — which is why the state survives restarts, exactly as you observed.

The one place the record contradicts you, and the arm that settles it

The package's own cost line says the opposite of your mechanism sentence. packages/sandbox/sandbox-windows-acl/README.md (§ Known Limitations) states: "Grant materialization is an eager full-tree propagation — SetNamedSecurityInfoW on a directory with inheritable ACEs walks every descendant immediately (tens of seconds on large workspace trees)", and grantWrite's own doc comment repeats it ("would otherwise re-propagate the identical descriptor across the whole tree"). Your sentence — the label is inheritable for future objects only — cannot be reconciled with that: if the apply walked the tree, the pre-existing directories in your table would carry the label.

The test suite does not settle it either. The only inheritance assertion in the package (tests/acl.spec.ts, "the ambient-delete deny inherits to subdirectories only, never onto files") calls grantWrite before mkdirSync, so every child the tests ever observe was created after the apply; no test under sandbox-windows-acl/tests creates one before.

This matters because it decides which fix is sufficient, and the two are not the same:

• if the apply does propagate, the whole defect is the root-only skip, and making that predicate tree-aware is enough;
• if it does not, provisioning needs a descendant walk added to it.

Your _dshprobe cannot separate them, because it was created after the grant. The arm that can: a workspace root that does not yet carry the exact triple (a fresh one) with a child directory created before the first confined call — child labelled afterwards ⇒ the apply propagates; child still unlabelled ⇒ it does not. The record has carried this question since 2026-09-19, and that single observation would close it.

What is new here, and it is worth more than the confirmation

1. /T crosses junctions — with numbers. 1,576 junctions and 31,718 objects labelled outside the workspace is the strongest statement of this boundary I have seen, and it is a boundary on exactly the repair this family keeps proposing. The repository already implements the safe shape you recommend: the bundled diagnosis script refuses a path whose ancestor chain traverses a reparse point (assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1:268-273) and skips reparse points inside its subtree scan (:304), with the rule in its own comment — "no reparse point or managed application tree is entered" (:280). Your distinction between the two icacls forms is the sharper half: icacls /grant without /T is safe because the inheritable ACE propagates by ordinary inheritance, which stops at the junction, whereas /T re-implements the walk and does not. I had not seen that stated anywhere in these threads.

2. The cross-workspace delete, measured. Your reading is the shipped rationale verbatim — the backend's mechanism section: "Windows can also authorize a write or a delete from the parent directory's FILE_DELETE_CHILD right, which no restricting SID has to co-sign" (README.md:98, restated at :123), and it is the reason the three edits ride one call (src/acl.ts:405-412) rather than being applied separately. What your report adds and the documentation does not have is the magnitude and the procedure: a label-only repair on a root with no world delete-child deny opens deletion of objects in every other Low-labelled root, and the fix is the one ACE. Note the shipped configuration cannot produce this on its own — the deny goes out with the label in the same call — so what you measured is the cost of a partial hand repair, which is precisely what a repair recipe has to spell out.

3. That is a fourth boundary on the relabel. The whole-tree relabel this family keeps proposing (icacls <root> /setintegritylevel (OI)(CI)Low /T) is recorded as the reporter's procedure and not as a supported remedy, and it already travels with three boundaries: it relabels objects that were never denied; it cannot name the derived capability SID (ERROR_NONE_MAPPED, 1332, a ceiling that extends to the removal direction); and it leaves the tree writable by every Low-integrity process on the machine. Your junction measurement is the fourth, and it is being recorded with the others.

On the documentation you asked for

The natural home is the Known Limitations bullet quoted above, which currently prices the propagation as a cost but does not say that a workspace predating an upgrade can be left half-labelled. There is one thing to be plain about if such a note is written: there is no supported repair command to point at. The bundled skill is DACL-only by construction — its SetNamedSecurityInfoW passes IntPtr.Zero for the SACL and its own comment says so, "Only the DACL and its inheritance protection are written: never owner, group or SACL" (diagnose-windows-sandbox-acl.ps1:190-192) — so it can report LOW_LABEL and cannot write it. The only route available today is your relabel, with the four boundaries beside it.

Where a fix can and cannot come from

The fix is core: either the skip predicate in src/acl.ts:386-395 becomes tree-aware, or provisioning gains a descendant walk — and the shape you propose (walk once, label what lacks it, skip reparse points) is the right one, with the note that the walk has to be tracked separately from the root's exact triple, or the same short-circuit that makes re-provisioning cheap will keep skipping the subtree.

A plugin cannot repair this. Writing the SACL needs WRITE_OWNER on each object and an unconfined caller, and the confined token has neither. What a plugin can do is name the shape before a user spends a day on DACL grants, which is what this already does — @argszero/cordis-plugin-sandbox-grant-advisor (npm: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor) recognizes an in-workspace denial from the executors' own stamp (sandbox: { mode: "workspace-write", denied: true }), forks on breadth, and in the branch that covers your case sends the reader to the one read that separates the halves: icacls <root> carries the Mandatory Label and the S-1-4-… ACE, icacls <root>\<sub> carries neither, or carries the ACE and no label. It never edits an ACL and ships no repair command.

Thank you for the before/after evidence and for pushing the repair question as far as you did — the junction numbers in particular are a finding in their own right.

[LimeError32]

Thanks for the detailed investigation. I independently reproduced the same issue on Windows 10 with DeepSeek Harness 0.2.1-rc.2, and completed a successful local workaround with additional inheritance tests.

Environment and reproduction

• Windows 10, PowerShell 5.1, non-elevated user

• Local NTFS volume; existing workspace containing 2,010 directories (including the workspace root) and 3,087 files

• Sandbox mode: workspace-write

• Existing directories had inheritance enabled (unprotected DACLs)

Initially, sandbox initialization failed with SetNamedSecurityInfoW failed (Win32 5): grantWrite(...) because the workspace owner lacked WRITE_OWNER. Granting (WO) to the current user on the workspace root allowed initialization to succeed.

This initial failure is separate from the inheritance issue discussed here.

After initialization, only the workspace root received the capability-SID ACE, the Everyone delete-child deny ACE, and the Low mandatory integrity label. Pre-existing descendants remained without these entries even after more than 40 minutes.

The confined shell could create files at the workspace root and inside newly created directories, but could not modify existing files or create files inside existing subdirectories.

Additional inheritance findings

I then tested how the existing tree responds to ACL writes performed with icacls, rather than DSH's provisioning call:

1. A single icacls /grant operation on an existing subdirectory, adding a non-inheritable (WO) ACE, triggered DACL inheritance updates. Within seconds, existing descendants acquired the previously missing sandbox capability ACE; a descendant directory also acquired the Everyone delete-child deny ACE. This shows that the newly added ACE itself did not need to be inheritable to trigger the update.

2. Subsequently, adding an inheritable (OI)(CI)(WO) ACE at the workspace root propagated (I)(WO) to a deeply nested existing file within 0.7 seconds. The capability ACE was already present in that subtree following the earlier operation, so this test independently confirms the propagation of (WO), not the capability ACE.

3. The same deep file still lacked a Low integrity label immediately after the DACL update, but acquired one later without an explicit per-file label operation. Before the residual label-repair passes:

   • 1,790 / 2,010 directories already had the expected Low label (OI|CI, NW).

   • 3,048 / 3,087 files already had a Low label with NW.

   • Only 220 directories and 39 files required explicit label updates. Both passes completed with zero failures.

These observations support the conclusion that an icacls-mediated inheritance refresh can update existing descendants, rather than affecting only newly created objects.

The integrity labels appeared later than the DACL entries, but the observations do not establish whether this was delayed propagation or the result of intervening ACL operations.

Full per-object labeling was not necessary in this case, although a residual set of objects still required explicit repair.

End-to-end verification

After the local repair, I tested the confined shell without disabling sandbox restrictions:

Test | Result -- | -- Open 4 pre-existing files for writing at different depths | 4/4 passed; SHA-256 unchanged Create, read, and delete temporary files inside 4 pre-existing directories | 4/4 passed Create a file outside the allowed workspace | Denied Create a directory outside the allowed workspace | Denied Read a file outside the allowed workspace | Succeeded Sandbox/runner initialization | Succeeded

The external write attempts produced UnauthorizedAccessException inside normally running child processes, rather than sandbox initialization failures.

The repair scan found no reparse points.

Possible upstream follow-up

The provisioning path uses SetNamedSecurityInfoW with DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION (0x14). It may be worth investigating whether an explicit inheritance refresh is required, potentially involving UNPROTECTED_DACL_SECURITY_INFORMATION (0x20000000) or a TreeSetNamedSecurityInfo-style operation.

These are possible investigation paths, not confirmed fixes.

A post-provisioning check of pre-existing child directories and files could also help detect missing capability ACEs, directory delete-child deny ACEs, or Low integrity labels before reporting sandbox initialization as successful.

Separately, the initial Win32 5 failure resulted from a missing WRITE_OWNER permission on a workspace inheriting a default data-volume ACL (Authenticated Users: Modify). An actionable error message or clearer documentation of this prerequisite would help users diagnose that failure.

The local workaround has been verified, but I have not confirmed a specific upstream code change as the fix.

Hopefully these additional results help narrow down the root cause.