# [Windows] 非系统盘工作区在 sandbox provisioning 阶段 fail-closed（Win32 5），且唯一官方修复手段与「避免 Low 完整性标签副作用」不可兼得

[TowardsDawn]

TL;DR

在非系统盘上使用 DSH（工作区如 E:\MyWorkspace），只要该目录的 ACL 是 Windows 盘的默认继承形态，grantWrite 就会抛 Win32 5 并 fail-closed —— 所有 pwsh / bash / run_code 类工具全部不可用，且每条命令都以同一个错误失败，没有任何可用性降级路径。

0.2.0 引入的 diagnose-windows-sandbox-acl 技能确实能修好它（补 WRITE_OWNER），但修好的同时会把 Low 完整性标签写回工作区，导致两个长期副作用回归。也就是说："沙箱能用" 和 "没有 Low 标签副作用" 目前只能二选一。

---

环境

项	值
OS	Windows 11 (AMD64)
工作区	E:\MyWorkspace（非系统盘，NTFS）
DSH	0.1.7-rc.2（Web / TUI）与 Desktop 0.2.0-rc.2 均可复现
沙箱包	@deepseek-ai/dsh-sandbox-windows-acl 0.1.7-rc.2 / 0.2.0-rc.2（两者 grantWrite 逻辑一致，见附录 A）
数据目录	%USERPROFILE%\.dsh（与工作区分属不同盘）

工作区 ACL（icacls 关键行，脱敏）：

E:\MyWorkspace  BUILTIN\Administrators:(I)(F)
                NT AUTHORITY\SYSTEM:(I)(F)
                BUILTIN\Users:(I)(RX)
                Authenticated Users:(I)(M)      ← 继承自 E:\ 盘根默认 ACL
                <owner>:(F)                      ← 用户手动加过，之后又移除（原因见痛点 3）

---

复现

1. 在非系统盘（E: / D: / F:）创建一个目录作为工作区，不做任何 ACL 调整（即保持盘根继承的 Authenticated Users:(M)）。
2. 启动 DSH（Web 或 Desktop 均可），以该目录为工作区。
3. 执行任意 pwsh 工具调用，例如 Get-Location。
4. 得到：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(E:\MyWorkspace)

5. 此后任何命令都返回同一个错误 —— 包括只读命令，因为失败发生在 spawn 之前的沙箱 provisioning 阶段。

---

痛点（本 issue 的重点）

痛点 1：最常见的用户目录形态，恰好是最容易触发失败的形态

grantWrite 的注释自己写明了前置条件（lib/types-*.js，0.1.7 与 0.2.0 措辞一致）：

The directory must be owned by the caller AND grant WRITE_OWNER (the label lives in the SACL; owner-implicit rights cover only READ_CONTROL and WRITE_DAC) — a Full-control workspace satisfies both.

问题在于：

• 非系统盘的盘根默认 ACL 给的是 Authenticated Users:(M)（Modify），不含 WRITE_OWNER；
• 目录 owner 的隐式权限只有 READ_CONTROL + WRITE_DAC，也不含 WRITE_OWNER；
• 因此"用户自己新建一个目录当工作区"这个最自然的行为，产生的正是会失败的 ACL 形态。

也就是说这不是边缘 case，而是默认路径上的坑。而且系统盘（C:\）下用户目录常常带 (F)，所以问题会呈现为"换个盘就炸"，进一步增加迷惑性。

痛点 2：失败发生在 provisioning 阶段，表现为"整个工具面消失"

grantWrite 失败是 fail-closed by construction（注释原话："throws on ANY Win32 failure — never spawns unrestricted"）。设计上可以理解，但用户体验是：

• 不是某条命令写不进去，而是所有命令都跑不了，连 whoami 都不行；
• 失败点在 spawn 之前，所以没有任何"部分可用"降级；
• 每个 profile 独立 provisioning，所以 Web / TUI / Desktop 会各自重踩一遍同一个坑；
• 用户无法从 Win32 5 + grantWrite(<path>) 推断出"缺 WRITE_OWNER"，更不知道有一个诊断技能可用。错误信息里没有任何指向解法的线索。

痛点 3：唯一官方修复手段，与「避免 Low 标签副作用」互斥 —— 这是本 issue 的核心

0.2.0 的 diagnose-windows-sandbox-acl 技能对本文场景的裁决是 PRECONDITION，动作是给当前用户补 FullControl allow ACE。补完之后 grantWrite 成功，一切正常。

但 grantWrite 成功时，那一次 SetNamedSecurityInfoW 是三处编辑一起落地的（源码注释）：

Each grant applies three edits in ONE SetNamedSecurityInfoW call: the capability-SID allow ACE, the deny of FILE_DELETE_CHILD to the world SID, and a Low no-write-up mandatory label.

于是：

加 FullControl  →  grantWrite 成功  →  Low 标签下发   ← 副作用回归
          移除 FullControl  →  grantWrite 失败  →  降级不打标签  ← 沙箱不可用

这两种状态互为前提，中间没有落脚点。 用户想要的是"沙箱能用，但工作区保持 Medium"，而当前架构下这个组合不存在。

而且由于 grantWrite 的幂等 skip 判据是 exact ACE + exact deny + exact Low label 三者齐备，用户也无法用 icacls /setintegritylevel Medium 手工把标签改回 Medium 来"骗过" skip —— 标签一旦与 Low 不符，apply 分支就会重新执行，再次写回 Low。

痛点 4：Low 标签的副作用被明确划到 scope 之外，但用户每天都在撞

官方 README 承认了 Low 标签会外溢：

A standing Low label outlives DSH and widens the tree for other Low-integrity processes — the workspace's inheritable label survives the session (and same-volume moves) …

技能文档则直接把后果排除在修复范围外：

Low executable labels and their effects outside DSH are outside this repair's scope.

但实际观察到的两个副作用都是用户可见、持久、且会传播到 DSH 之外的：

4a. 工作区内双击 .bat / .exe 时出现「无法验证发布者」警告。 用户在自己刚创建的脚本上双击，得到的是安全警告 —— 这直接破坏"工作区就是我的目录"的直觉。

4b.（更严重）把工作区里的文件复制出去，文件会被写上 Zone.Identifier ADS（ZoneId=3，即 MOTW）。 这条最要命：

• 它是静默的 —— 用户不知道文件被打了标记；
• 它会跟着文件走 —— 把标了 MOTW 的文件发给同事，对方打开时触发 SmartScreen / 受保护视图；
• 它跨程序生效 —— 与 DSH 无关的编辑器、压缩工具、同步工具都会读出这个 ADS；
• 它是持久的 —— 即使 DSH 卸载、工作区改名，ADS 仍然依附在文件上。

也就是说：DSH 在"只是跑了个命令"之后，悄悄改变了用户文件的元数据，并让这个改变传播到 DSH 之外的环境。 这是我们认为最需要优先解决的一点。

补充说明：这一条是在移除 FullControl 让 grant 失败之后才消失的 —— 反过来说，官方修复手段必然让它回来。

痛点 5：修沙箱的工具，需要沙箱能用才能跑（鸡生蛋）

diagnose-windows-sandbox-acl 是一份 PowerShell 脚本（assets/diagnose-windows-sandbox-acl/scripts/*.ps1，约 45 KB / 798 行），必须用 pwsh 执行。

但故障场景恰恰是 pwsh 工具完全不可用（痛点 2）。技能文档也确认沙箱内无法运行：

The script writes permissions, which the confined token cannot do — run it there and it would report the sandbox's own restriction as a missing right — so request approval for that one command and run it unconfined. A confined run of the script is never useful.

结论是一个没有出口的循环：

• 在 DSH 内跑 → 沙箱令牌写不了 ACL，无效；
• 在 DSH 外跑 → 需要用户知道脚本在哪、怎么调，而文档没有给出这条路径的操作说明；
• 想让 DSH 内以非沙箱方式跑 → 只能把整个会话切成「完全权限」(full access)，等于临时关掉沙箱去修沙箱。

建议：把该技能的调用路径做成"沙箱不可用时也能一键触发"的形态（例如由 host 端直接执行并走 approval，而不是依赖 pwsh 工具）。

痛点 6：诊断脚本住在临时目录，DSH 一重启就消失

registerAclDiagnosisSkill() 的实现是解压到 mkdtempSync(join(tmpdir(), "dsh-acl-skill-"))，并且 "disposal removes the directory"。后果：

• 路径每次启动都变（随机后缀），无法收藏、无法写进文档、无法做书签；
• 用户想以后复用这个工具，必须自己手动复制出来；
• 而"什么时候该复制"本身需要用户先知道这个坑 —— 又一次是先有故障才有认知。

技能文档只提醒了不要把 -Out 放进去，没有提示"想留下工具请自行复制"。

---

已经做得好的部分（希望保留）

不是全盘否定，以下几点确实到位：

1. 0.2.0 新增 diagnose-windows-sandbox-acl 技能，第一次给了官方诊断入口，而不是让用户自己 grep 源码；
2. 修复是带备份、带回读验证、失败自动反向回滚的，还提供了 ROLLBACK 命令和（脚本级）-Restore 模式，工程上比"手敲 icacls"稳得多；
3. -AllowRoot 把改动范围锁死在授权目录内，并拒绝 reparse point 和受管应用目录；
4. 明确承诺 不碰文件内容、不碰 owner、不删 deny ACE、不提权；
5. 文档诚实 —— 前置条件、边界、已知局限都写清楚了（READ-ONLY 的约束、FILE_DELETE_CHILD 只继承到目录、hard link 与 AppContainer ACL 的边界等）。

---

期望

按优先级：

1. 提供"降级 provisioning"模式（最高优先级）：当 SetNamedSecurityInfoW 因缺少 WRITE_OWNER 而失败时，允许退化为 DACL-only（应用 capability-SID allow ACE + Everyone deny，跳过 SACL 的 Low 标签编辑），并明确告知这是一次降级。理由：write-restricted token 的 restricting-SID 交集检查是主要的强制机制，Low 标签是纵深防御的第二层；牺牲第二层换取可用性，比 fail-closed 更符合实际。这也是社区补丁被迫采用的方案（附录 B）。

2. 把 grantWrite 的三处编辑拆开，让 Low 标签可独立开关。当前"一次调用三件事"的设计使得用户无法只取 DACL 部分，这是痛点 3 的根因。

3. 区分处置 4a / 4b：至少不该因"创建文件的方式"而给文件写 MOTW。如果 4b 的成因确实是标签策略导致的 ADS 写入，请把它纳入修复范围，而不是排除在 scope 外。

4. 启动期预检 + 可操作的错误信息：在 provisioning 必然失败时，启动日志/UI 直接给出"缺 WRITE_OWNER，可运行 diagnose-windows-sandbox-acl"的提示，而不是让每条命令都重复 Win32 5。非系统盘工作区应单独给出提示（这正是最容易踩的形态）。

5. 让诊断技能在沙箱不可用时也能被触发：走 host 端 + approval，不依赖 pwsh 工具链（痛点 5）。

6. 技能资源放到持久位置，或提供一行命令让用户自行持久化（痛点 6）。

---

附录 A：grantWrite 在 0.1.7-rc.2 与 0.2.0-rc.2 之间未变

对比两份打包产物（lib/types-*.js）：

• 幂等 skip 判据相同：hasExactGrant(oldAcl, sidPtr) && hasExactDeny(oldAcl, worldSidPtr) && hasExactLabel(labelAcl, lowLabelSidPtr)；
• apply 分支相同：mergeAndApply(api, path, Buffer.concat([buildExplicitAccess(worldSidPtr, 3, 64, 2), buildExplicitAccess(sidPtr, 1, GRANT_MASK)]), oldAcl, { kind: "apply", acl: label }, descriptor, "grantWrite")；
• koffi 绑定签名相同：setNamedSecurityInfoW 为 7 参数（str16, int, uint32, PVOID ×4），getNamedSecurityInfoW 为 8 参数；
• 唯一实质新增是 ACL_DIAGNOSIS_SKILL / registerAclDiagnosisSkill 以及 assets/ 目录。

结论：0.2.0 修的是"诊断与修复的可用性"，不是"这个前置条件本身"。 因此本 issue 描述的故障在 0.2.0-rc.2 上原样复现。

附录 B：社区已被迫用 koffi hook 绕过

社区侧存在 dsh-acl-sandbox-patch 这类插件，做法是在 SetNamedSecurityInfoW 收到 Win32 5 时剥离 LABEL | SACL 标志重试，即只应用 DACL 部分，并在进程内标记"降级"状态，同时跳过子进程的 SetTokenInformation(TokenIntegrityLevel)。

它的存在本身就是对痛点 3 的佐证：用户想要的是"沙箱能授权"而不是"沙箱能打标签"，而当前 API 只提供后者。同时它也说明痛点 1/2 的修复需求足够普遍，以至于有人愿意维护一个第三方 hook。

（此处不主张官方采用任何具体第三方实现，仅作为需求强度的证据。）

---

[argszero]

Two of your six pain points are answered by a mechanism rather than a policy decision, and one of your expectations comes out differently once that mechanism is on the table. The rest are yours to argue upstream — I am not upstream.

1. The either-or is real, but the label is not one of two independent layers

Your framing is right as a description of the shipped API, and your附录 A is right that grantWrite is unchanged between the two lines. What changes is what "degrade to DACL-only" would actually mean, and it is more than declining a defence-in-depth layer.

Read off the shipped source (packages/sandbox/sandbox-windows-acl):

• There is no DACL-only apply path to fall back to. The two edits go out together: mergeAndApply passes labelEdit.kind === 'keep' ? DACL_SECURITY_INFORMATION : DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION (src/acl.ts), and grantWrite's apply branch always passes { kind: 'apply', acl: label } — keep exists for revokeWrite, not for a grant. Your expectation 2 (split the three edits) is therefore not a refactor; it is new surface, and you are right to ask for it as such.
• The label is load-bearing, not a second layer. The confined token is itself lowered before any child starts — restrictTokenIntegrity(api, restrictedToken, lowLabelSid) in src/index.ts, implemented by SetTokenInformation(token, TokenIntegrityLevel, …) in src/token.ts, whose own comment calls Low "the level the mandatory labels grantWrite applies are matched against". Under no-write-up, an object's Low label is what lets a Low subject write to it at all. A DACL-only grant that keeps the token lowering hands you a workspace the sandbox can start a command in and the command cannot write to.

That is why your附录 B's community patch had to skip SetTokenInformation(TokenIntegrityLevel) as well as stripping LABEL | SACL. Both edits, or neither — and "both" is where your痛点 3's either-or actually lives: what is being traded is the token's level, not one of two independent defences. Your expectation 1 is achievable; the form it has to take is "drop the label and the token lowering together", which is a different proposal from the one written up, and stronger for saying so.

2. 痛点 5 has an answer that does not need a shell

You are right that the skill cannot solve its own no-shell problem: a script needs pwsh, and this failure is the reason pwsh does not run. But a diagnosis does not have to be a script. @argszero/cordis-plugin-sandbox-grant-advisor — released at 0.9.1 for this thread together with discussion #8272 — is an npm plugin that is loaded by the harness and speaks on the failed tool result itself, so it works in exactly the state you describe:

npm install @argszero/cordis-plugin-sandbox-grant-advisor

- insert:
    - id: sandbox-grant-advisor
      name: '@argszero/cordis-plugin-sandbox-grant-advisor'

It observes the public tools/post-execute waterfall, recognizes this signature (only the two ...NamedSecurityInfoW operations), and attaches one durable user-role advisory per agent per family through additionalContexts. It never edits an ACL, never elevates, never changes a mode and never sets another process's environment — so it is the "diagnosis reaches you while the sandbox is down" half of your痛点 2 and痛点 5, not a repair.

3. What it now says about your痛点 3

This is what 0.9.1 added, and it is your report's shape rather than your report's proposal:

One thing to know before asking for a weaker grant, because that is the next idea after this diagnosis — and it is not a smaller version of the same grant: the label rides the SAME SetNamedSecurityInfoW as the DACL (one call, two security-information flags), so there is no DACL-only path to fall back to — it would have to be built. And dropping the label alone would not leave a working workspace: the backend lowers the confined token to Low before any child starts … a workspace that keeps the token lowering but not the label is one the sandbox can start a command in and the command then cannot write to. Declining the label usefully means declining the token's Low level with it — which gives up half the confinement rather than one of two independent layers.

It is phrased as a mechanism rather than a refusal on purpose: a reader told only "no" reaches for the workaround without knowing what else it has to change, which is the failure mode your附录 B documents from the outside.

4. What I am not taking a position on

• 4a / 4b. Both are your observations on a Windows host, and I have none, so I can neither confirm nor derive them. Your own note that 4b disappears when the grant is made to fail again is consistent with the label being involved, but "consistent" is all it is — the label is inherited by everything created under the workspace, and the mechanism by which that would produce a Zone.Identifier ADS is not something this plugin can claim. Expectation 3 is an upstream call.
• 痛点 6 (the skill's scratch directory) and the repair script's scope. Neither is reachable from a plugin.

Verified for the release named above: 86 tests green, 32 defect-injection arms (31 caught, one measured equivalent, none silent), all five peer lines re-probed; 0.2.0-rc.2 — the Desktop build you reproduce on — was probed separately and the same suite goes green there. That is recorded as a measurement rather than a claim, because the plugin's declared peer range stops below 0.2.0 and I would rather say so than imply coverage the range does not carry.