[Bug Report] Windows workspace-write：目录 DACL 缺少 WRITE_OWNER 时，所有受限 shell 调用以原始 SetNamedSecurityInfoW Win32 5 失败（0.1.7-rc.2 无内置诊断/修复路径）

[ESTvoider]

Summary

在 Windows 上以非提权账户、文件策略为 workspace-write 时，工作区目录的 DACL 若只授予 Modify（即没有 WRITE_OWNER），沙箱的每一次授权都会失败：

SetNamedSecurityInfoW failed (Win32 5): grantWrite(X:\DeepSeek Harness\DSH-Common)

沙箱按设计 fail-closed，于是所有受限 shell 调用都不可用（pwsh 工具完全无法使用），而且错误信息里既没有指出缺失的权限，也没有指向任何修复入口。同机切到 danger-full-access（跳过授权）后立刻恢复正常，说明后端其余部分工作正常。

这本身符合 dsh-sandbox-windows-acl 已记录的边界（"被授权目录必须由调用者拥有并授予 WRITE_OWNER……DACL 只授予 Modify 的目录现在会大声失败"），因此本报告的重点不是"失败了"，而是这个失败在 0.1.7-rc.2 上不可行动：README 承诺的内置 diagnose-windows-sandbox-acl 诊断/修复技能在该版本没有随包发布。

Reproduction

环境（详见 Environment）：Windows 11 26200.9168，账户 <MACHINE>\<user>（Medium 完整性 / 非提权），@deepseek-ai/dsh@0.1.7-rc.2 全局 npm 安装，DSH_HOME=C:\Users\<user>\.dsh，profile web，工作区在非系统盘。文中盘符统一写作 X:，机器名/用户名写作 <MACHINE> / <user>。

1. 确认工作区目录的 ACL 只给当前用户 Modify：

> icacls "X:\DeepSeek Harness\DSH-Common"
X:\DeepSeek Harness\DSH-Common S-1-4-60829086-371263548:(OI)(CI)(W,D,DC)
                               S-1-4-979659899-60949555:(I)(OI)(CI)(W,D,DC)
                               BUILTIN\Administrators:(I)(F)
                               BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
                               NT AUTHORITY\SYSTEM:(I)(F)
                               NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
                               NT AUTHORITY\Authenticated Users:(I)(M)
                               NT AUTHORITY\Authenticated Users:(I)(OI)(CI)(IO)(M)
                               BUILTIN\Users:(I)(RX)
                               BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)

> icacls "X:\DeepSeek Harness"
X:\DeepSeek Harness S-1-4-979659899-60949555:(OI)(CI)(W,D,DC)
                    BUILTIN\Administrators:(I)(F)
                    ... NT AUTHORITY\Authenticated Users:(I)(M) ...

（S-1-4-* 是后端派生/随机的能力 SID；调用者自身只有经 Authenticated Users 继承来的 M。目录所有者是当前用户。）

2. 确认令牌没有任何可用来合并写入的特权：

> whoami /priv | findstr /i "SeRelabel SeSecurity SeTakeOwnership SeRestore"
（无输出 —— 四项特权均不在非提权令牌中）

3. 关键判别：在一个自己新建、自己拥有的目录上单独执行三处修改里的第三处（Low 完整性标签），同样被拒：

> icacls "X:\DeepSeek Harness\DSH-Common\.acl-probe" /setintegritylevel "(OI)(CI)Low"
X:\DeepSeek Harness\DSH-Common\.acl-probe: Access is denied.
Successfully processed 0 files; Failed processing 1 files

4. 正常启动 dsh（配置 workspace-write），调用 pwsh 工具的任意命令 → 复现上文的 SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)；同一进程把策略切到 danger-full-access 后同一命令立刻成功。

我这里的复现跨越三次 dsh 重启都稳定一致（升级前 0.1.5-rc.1 完全正常）。

Current behavior

• workspace-write 下所有受限 shell 调用失败，错误只有一行原始 Win32 文本，例如：
  Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(X:\DeepSeek Harness\DSH-Common)
• 错误信息未指出缺失的是 WRITE_OWNER（标签位于 SACL，因此合并应用需要它），也未给出任何补救路径。
• 用户/Agent 会误以为是"沙箱坏了"或"没重启"；实际只需给自己的目录补上完全控制（见 Workaround）。
• 在本版本（0.1.7-rc.2）上，README 提到的内置诊断/修复技能不可用：
  • @deepseek-ai/dsh-sandbox-windows-acl@0.1.7-rc.2 的 package.json 中
    "files": ["lib/index.js","lib/runner.js","lib/types-*.js","lib/types/**/*.d.ts"] —— 不含 assets；实际安装目录下也确实没有 assets/。
  • @deepseek-ai/dsh-sandbox-local@0.1.7-rc.2 的 lib/*.js 中检索不到 registerAclDiagnosisSkill / diagnose-windows-sandbox-acl 任何字样。
  • 对照 master（0.2.0-rc.2）：files 已包含 "assets"，并新增 @deepseek-ai/dsh-skill 与 yaml 依赖。
    → 也就是说："失败"是设计，"失败后无路可走"是 0.1.7-rc.2 的缺口。

Expected behavior

任一即可：

1. 失败信息自解释：明确指出被拒的是合并写入中的 Low 完整性标签（SACL），缺少的是被授权目录上的 WRITE_OWNER（所有者只隐含 READ_CONTROL/WRITE_DAC），并给出可执行的修复提示（例如在链路目录上为当前用户授予完全控制）。
2. 或在调用者拥有有效 WRITE_DAC 时自修复：为其补上缺失的允许 ACE（正是随包诊断脚本的语义），而不是直接 fail-closed。
3. 至少让 diagnose-windows-sandbox-acl 在 0.1.7 线上也可用（或回填说明"该技能自 0.2.0 起提供"），避免 npm 安装的用户按 README 找不到它。

Environment

• dsh：@deepseek-ai/dsh@0.1.7-rc.2（全局 npm 安装；同机另有 0.1.5-rc.1 时一切正常）
• profile：web（bundles：dsh-base、dsh-web-app、dshmarket、dsh-context、dsh-zh、dsh-blender、dsh-comfyui、dsh-experimental-agent-team-profile）
• OS：Windows 11 10.0.26200.9168（x86_64），账户 Medium 完整性、非提权
• 工作区：X:\DeepSeek Harness\DSH-Common（所有者 = 当前用户；调用者仅 Authenticated Users:M）
• 沙箱相关包：dsh-sandbox-windows-acl@0.1.7-rc.2、dsh-sandbox-local@0.1.7-rc.2、dsh-pwsh-sandbox@0.1.7-rc.2
• 文件策略：workspace-write（失败）/ danger-full-access（同一命令成功）

Workaround（本机已验证方向）

因为目录所有者隐含 WRITE_DAC，无需提权即可补齐 WRITE_OWNER（与随包诊断脚本的修复语义一致：为链路上缺少 WRITE_DAC/WRITE_OWNER 的目录补当前用户完全控制）：

icacls "X:\DeepSeek Harness" /grant "%USERNAME%":(OI)(CI)F
icacls "X:\DeepSeek Harness\DSH-Common" /grant "%USERNAME%":(OI)(CI)F

替代方案：把文件策略设为 danger-full-access（授权步骤被跳过，已验证可用），或以管理员身份启动 dsh（令牌具备相应特权）。

附：相关源码/文档位置

• 边界声明：packages/sandbox/sandbox-windows-acl/README.zh.md → 「已验证边界」中"被授权目录必须由调用者拥有并授予 WRITE_OWNER……DACL 只授予 Modify 的目录现在会大声失败，而不是静默跳过隔离"
• 三处合并写入：packages/sandbox/sandbox-windows-acl/src/acl.ts（grantWrite：能力 SID 允许 ACE + world SID 的 FILE_DELETE_CHILD 拒绝 + Low 禁止上调标签，单次 SetNamedSecurityInfoW）
• 诊断/修复技能（master）：packages/sandbox/sandbox-windows-acl/assets/diagnose-windows-sandbox-acl/

[argszero]

One correction, one credit, and one thing that may save you the wait.

1. The skill is not missing from 0.1.7-rc.2 — it does not exist there yet

Your expected-behaviour item 3 offers two alternatives — backport the skill to the 0.1.7 line, or document that it is available from 0.2.0. The second is the accurate one, and it is the reading that changes the fix: repairing the files glob on the 0.1.7 line would change nothing, because that release has nothing to include.

Measured on both published tarballs (2026-09-29):

	@deepseek-ai/dsh-sandbox-windows-acl@0.1.7-rc.2	@deepseek-ai/dsh-sandbox-windows-acl@0.2.0-rc.2
files in package.json	lib/index.js, lib/runner.js, lib/types-*.js, lib/types/**/*.d.ts	the same array plus assets
assets/ in the tarball	0 files — the directory is not there	2: assets/diagnose-windows-sandbox-acl/SKILL.md and assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1
diagnose-windows-sandbox-acl in README.md / README.zh.md	0 / 0	3 / 3
registerAclDiagnosisSkill anywhere in the 0.1.7-rc.2 source tree	0 files	—

So the 0.1.7-rc.2 files array is exactly right for a package that has no assets, and the promise you held it against lives in a 0.2.0-era document. That is version skew between the document and the install, not a glob that dropped a directory — and it is worth stating as a boundary ("the skill arrives with 0.2.0") rather than as a packaging defect, because the two lead a reader to different actions: one upgrades, the other goes looking for a files entry that cannot be fixed.

Your own附 section already saw the shape of this (master has "assets" and the two new dependencies). The only piece that flips is which side is the anomaly.

2. Your item 3 is the best discriminator this family has, and it should not be scripted

icacls <dir> /setintegritylevel "(OI)(CI)Low" on a directory you own, unelevated, refused — that isolates the label half of the merged write, which is the half that needs WRITE_OWNER, without asking anyone to interpret one failure that covers both halves at once. Every earlier report in this family had to reason from the merged error; you measured the halves apart. Thank you for that.

It is deliberately not turned into a checklist step, and the reason is a property of the probe rather than of your run: where the caller holds Full control on the directory, the same command succeeds — and then the Low label, and its inheritance, are already written. That is precisely the side effect discussion #8275 is about. A diagnostic that mutates when it succeeds is not one to hand out as a check; in your run it was denied, so nothing changed and the observation stands.

3. The stopgap, for the part that is still unfixed

The missing-right diagnosis and the remedy now ship as an npm plugin — @argszero/cordis-plugin-sandbox-grant-advisor, released at 0.9.1 for this thread together with discussion #8275:

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 (and only this one — the two ...NamedSecurityInfoW operations), and attaches one durable user-role advisory per agent per family through additionalContexts, so the model gets the diagnosis in the same step as the failure instead of retrying a command that cannot start. It never edits an ACL, never elevates, never changes a mode and never sets another process's environment.

Two things make it relevant here rather than merely adjacent:

• It is delivered through the session, not through a shell — which is exactly what this failure has removed. Your item 2 (self-repair) and # [Windows] 非系统盘工作区在 sandbox provisioning 阶段 fail-closed（Win32 5），且唯一官方修复手段与「避免 Low 完整性标签副作用」不可兼得 #8275's痛点 5 both run into that: the thing that would repair the workspace needs a shell that the failed provisioning took away. An advisory attached to the failed tool result does not.
• 0.9.1 states this thread's boundary: the backend's own skill is not part of the 0.1.7 line at all, it arrives with 0.2.0, so a reader who found the name in a README was reading a later document. The advisory says that instead of leaving the reader to conclude the package dropped something.

Verified: 86 tests green, 32 defect-injection arms (31 caught, one measured equivalent — the runtime derives the two reads from the same field, so the mutation is indistinguishable from outside — and none silent), all five peer lines re-probed; the 0.2.0-rc.2 build was probed separately and the same suite goes green there — recorded as a measurement rather than a claim, since the declared peer range still stops below 0.2.0.