[Bug] Windows 工作区供给：缺 world deny 时整树 ACL 重写会焊死宿主事件循环（0.2.0-rc.2 可复现，含源码定位）

[7889545]

注：本仓 issue 已关闭、CONTRIBUTING 也说明暂不接受外部 PR，故发到 Discussions。若需要最小复现工程或补丁草案，我可以整理附上。

环境

• DSH 0.2.0-rc.2（npm latest；Windows 11 / NTFS / pwsh 7）
• @deepseek-ai/dsh-sandbox-windows-acl 与 @deepseek-ai/dsh-sandbox-local 均 0.2.0-rc.2
• 已比对 0.2.1-alpha.4：上述两个包的 lib 文件 sha256 与 rc.2 完全一致，问题同样存在

症状

宿主 127.0.0.1:3080 无响应、所有会话停止写入；进程不崩、无错误日志，只能杀进程重启。根越大越致命 —— 实测 D:\projects 补齐时整树传播耗时 4490.6 秒（约 75 分钟），期间宿主全程无响应。

根因（读源码定位，非推断）

dsh-sandbox-windows-acl 的幂等跳过要求同一个根同时具备：① 工作区能力 ACE S-1-4-x-y:(OI)(CI)(W,D,DC)；② Everyone:(CI)(DENY)(DC)（world FILE_DELETE_CHILD deny）；③ Low 完整性标签。

缺任一条即走 mergeAndApply → SetNamedSecurityInfoW 做整树急切传播；而调用点 dsh-sandbox-local/lib/index.js:396-412 的 materializeAclGrant() 是同步、宿主进程内调用（AclWriteGrant.create(...).add(...)），Node 事件循环因此被焊死。

放大点：旧版本只授过 grant+label 的根，会在「下一次供给」时才补 deny —— 那一次就是整树重写。从旧版升级上来的用户，会在某次开新会话时突然卡死，且与那次操作毫无关系。

最小复现

1. 造一个只有 grant+label、没有 world deny 的工作区根（icacls 即可）
2. 启动 DSH，在 UI 里为该根打开会话（触发首次沙箱供给）
3. 宿主在供给期间失去响应；整树传播期间没有任何进度输出

建议（供参考，不要求采纳）

1. 幂等判据：别让 world deny 成为「要么全跳过、要么全树重写」的硬条件 —— 让补 deny 与 grant/label 走同一次 O(1) 供给
2. 移出事件循环：整树传播放子进程 / worker_threads，或至少让出（当前调用点是同步的）
3. 可观测性：整树操作给进度与耗时，并提供「先补根、后台补齐子项」的降级路径
4. 升级迁移：版本升级时预检并后台补齐 deny，别把成本推给用户的首次供给

我方临时缓解（本地，不影响上游）

预置三条件 + 启动横幅体检 + 加根闸门（缺项只告警）。需要的话可整理成独立工具附上。

附：定位证据

• 调用点：dsh-sandbox-local/lib/index.js:396-412（materializeAclGrant → AclWriteGrant.create().add()，同步）
• 幂等判据：dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js（hasExactGrant / hasExactDeny，后者要求 FILE_DELETE_CHILD deny 条目）
• 版本比对：0.2.0-rc.2 vs 0.2.1-alpha.4 的 index.js / runner.js / types-Cl_DXjhk.js sha256 全同

---

English abstract：On Windows, a workspace root that has the write grant + Low integrity label but no Everyone:(CI)(DENY)(DC) world FILE_DELETE_CHILD deny fails the fast-path idempotency check, so the first sandbox provision performs an eager full-tree SetNamedSecurityInfoW synchronously inside the host process (dsh-sandbox-local/lib/index.js:396-412), freezing the event loop (measured 4490.6 s on a large root; host unresponsive throughout). Roots provisioned by older builds only receive the deny on their next provision, so users hit this after upgrading, unrelated to what they did. Identical code in 0.2.1-alpha.4 (sha256 match).

[argszero]

Confirmed from the source, and the released-line boundary is narrower than "an old version".

I read this against 86a402200d (the dsh-v0.2.1-alpha.4 tree — your sha256 comparison says these two ACL packages are byte-identical to 0.2.0-rc.2, so one revision answers for both).

The skip is a three-way conjunction; the apply branch is the eager path. packages/sandbox/sandbox-windows-acl/src/acl.ts:387-388:

    if (oldAcl !== null && labelAcl !== null
      && hasExactGrant(oldAcl, sidPtr) && hasExactDeny(oldAcl, worldSidPtr)
      && hasExactLabel(labelAcl, lowLabelSidPtr)) {

Missing any one of the three falls through to mergeAndApply(...). The module's own docstring on grantWrite names the cost you measured, in its own words:

Idempotent: the exact ACE, deny, and label together SKIP the SetNamedSecurityInfoW apply, which would otherwise re-propagate the identical descriptor across the whole tree (eager inheritance; minutes on large workspaces).

So the eager full-tree propagation is not inferred from behaviour — it is written down in the source as the reason the fast path exists at all.

The call is synchronous, inside the host process, and nothing reports it. AclWriteGrant.add() calls grantWrite() directly (src/grant.ts:127); the Windows bindings are bound synchronously (win32Sync() at :66) and there is no await anywhere on that path. The call site is packages/sandbox/sandbox-local/src/index.ts:403 (materializeAclGrant), reached from windowsAclRunnerArgv() at :379 — that is, while the runner's argv is being assembled, before any child process exists. acl.ts contains no logger call and no console write at all, so the absence of progress during the propagation is structural rather than a gap in one branch.

The version boundary, pinned. The deny-and-label half of the skip arrived in dsh-v0.1.7-alpha.1 (commit 36e632751e, "fix(sandbox): deny the ambient parent-delete right inside granted roots"). On the line before it, dsh-v0.1.6-alpha.2's skip read:

    if (oldAcl !== null && hasExactGrant(oldAcl, sidPtr)) {

— grant only. A root provisioned by 0.1.6-alpha.2 or earlier therefore carries the capability ACE and nothing else, so the first provision by any 0.1.7-alpha.1-or-later build takes the apply branch on an already-granted root. That is the same release boundary that introduced the Low label, which is why "predates the deny" and "predates the label" name the same set of trees: your amplification point holds as stated, and it can be given as a version rather than as "an old version".

What is already written down, and what this report adds. We publish a diagnostic plugin for this backend's standing edits — npm @argszero/cordis-plugin-sandbox-grant-advisor, repo argszero/cordis-plugin-sandbox-grant-advisor. It states the three standing entries, that the root-only idempotency check requires all three (hasExactGrant() + hasExactDeny() + hasExactLabel()), and it quotes that same "eager full-tree propagation" sentence from the package README — but it reads the sentence as a statement about the ACE that is written rather than about what the children end up carrying, because the case it documents is the propagation that does not happen (the descendants that miss the label). This report supplies the other half: the one time the apply branch is taken on an already-granted root, the propagation is real, blocking and silent. That half is not in the plugin's text, and it is the more expensive of the two.

On the fix surface, honestly. The freeze itself is out of a plugin's reach: a synchronous SetNamedSecurityInfoW inside the host process cannot be preempted by a listener that same process is not running, so your points 2 and 3 are core changes. Your point 4 — detect and report the incomplete root before the first provision pays for it — is the part that is observational, and it is also the part that has to answer a question we cannot yet answer without a Windows host: whether the tri-condition can be read from the host process cheaply enough (and without spawning through the very sandbox that is being set up) to make a warning worth its own cost. If you already have that check in the local mitigation you mention, it would be the interesting half to see.

[ManniGH]

Data point from a Windows 11 Pro machine (account is a member of the local Administrators group; the DSH host process runs a UAC-filtered Medium IL token - verified: BUILTIN\Administrators is "Group used for deny only" in the token; the D: drive is owned by Administrators; workspace on the non-system D: drive, Dropbox-synced folder), covering 0.2.0-rc.2 and 0.1.7-rc.2:

• Same failure on both versions, at provisioning: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>); every confined pwsh is rejected.
• Diagnostic skill verdict: PRECONDITION - caller effective writeDac true, writeOwner false; 0 changes applied, nextAction stop.
• The caller is a local-admin account under a UAC-filtered Medium token, so this is not a plain standard-user case: the effective WRITE_OWNER right is absent from the filtered token's ACE evaluation on the workspace root (root owner: the user SID). Unverified reading: the missing WRITE_OWNER - and possibly an admin-only privilege for the Low-integrity-label part of the atomic grant - is why the re-grant is denied even though WRITE_DAC is effective.
• Root ACL anomaly: the capability ACE is present on the workspace root, but the world deny ACE and the Low mandatory-integrity label are missing. Unverified reading: the partial state fails the exact-ACE reuse match, so a re-grant is attempted and denied.
• Confirmed workaround (0.2.0-rc.2): icacls <workspace-root> /grant <affected-account>:(OI)(CI)(WO) - an explicit WRITE_OWNER ACE for the affected account - made confined pwsh provisioning succeed immediately (verified: commands run, file write and delete succeed). Consistent with the PRECONDITION diagnosis above (effective writeOwner false). The same ACE is also effective for the confined Low-IL child of that account, so this does not settle the open question below.
• Grant code byte-identical between 0.1.7-rc.2 and 0.2.0-rc.2 (per-package blob SHA comparison), consistent with the rc.2 vs 0.2.1-alpha.4 comparison in this thread.
• Other reports in this thread put the break between 0.1.5 and 0.1.7; that is likely what happened here, but we could not confirm by running 0.1.5-rc.1: the published 0.1.5-rc.1 manifest declares caret ranges on its ~50 subpackages, which today float to 0.1.5-rc.3 and break the plugin tree (fatal dsh: plugin tree failed to load: @deepseek-ai/dsh-sandbox-local after ~12,600 ERESOLVE warnings; 0.2.0-rc.2 exact-pins the subpackages and installs cleanly). So the byte-identity evidence above is the full version span currently testable.
• Open question from reading the installed bundle (lib\types-Cl_DXjhk.js, ~L985 vs ~L1278-1284): does the failing SetNamedSecurityInfoW run on the host caller token, or on the confined Low-IL WRITE_RESTRICTED child?