[Bug][Windows 10] workspace-write 沙箱下所有子进程 0xC0000142（连 cmd.exe 都起不来）— Default DACL 使用 capability SID 所致

[Ethan-H1K]

1、TL;DR
在 Windows 10 22H2 (19045) 上，DSH Desktop 0.2.0-rc.2 的 workspace-write 沙箱模式无法启动任何子进程——cmd.exe、where.exe、Windows PowerShell 5.1、PowerShell 7.6.6 全部以 0xC0000142 (STATUS_DLL_INIT_FAILED) 退出，没有任何 stdout/stderr。
同一台机器上 read-only 模式完全正常。
根因是受限令牌的 Default DACL 里挂的 trustee 是 capability SID（S-1-4-…），而不是 Everyone：
js
// @deepseek-ai/dsh-sandbox-windows-acl/lib/types-.js (AclSandbox.init())
setTokenDefaultDaclGrant(api, restrictedToken,
this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid); // ← 这一行
把这一个参数换成 worldSid（或在原有基础上再补一条 Everyone），workspace-write 立刻恢复正常（已实测 cmd.exe 与 PowerShell 7.6.6 均可正常运行）。

2. 复现
2.1 界面内复现（用户视角）
把会话的权限预设切到 workspace-write
执行任意命令，例如 cmd /c echo
实际返回（工具结果原文）：
json
{
"kind": "foreground",
"exitCode": 3221225794, // = 0xC0000142
"signal": null,
"stdout": { "text": "", "truncated": false },
"stderr": { "text": "", "truncated": false },
"sandbox": { "mode": "workspace-write", "denied": false, "enforcement": "partial" }
}
注意 denied: false：这不是"被沙箱拒绝"，而是进程根本没起来。

2.2 可脚本化复现（直接调用发行版自带的沙箱 runner）
不需要 GUI，直接调用 DSH 自带的 windows-acl runner，对照组与实验组只差一个 --mode：
powershell
$exe = '<DSH 安装目录>\DeepSeek Harness.exe' # 例：D:\Forest\DeepSeek Harness.exe
$runner = '<DSH 安装目录>\resources\app.asar\dsh\node_modules@deepseek-ai\dsh-sandbox-windows-acl\lib\runner.js'
$ws = '<任意已存在的工作区目录>' # 例：D:\Forest\default-workspace
$env:ELECTRON_RUN_AS_NODE = '1'
$o = "$env:TEMP\o.txt"; $e = "$env:TEMP\e.txt"

function Run([string]$mode) {
$a = '--expose-internals "' + $runner + '" --workspace "' + $ws + '" --temp "' + $env:TEMP +
'" --mode ' + $mode + ' -- "C:\Windows\System32\cmd.exe" /c "echo ok"'
$p = Start-Process -FilePath $exe -ArgumentList $a -Wait -PassThru -NoNewWindow `
-RedirectStandardOutput $o -RedirectStandardError $e
'{0,-16} exit=0x{1:X8} out={2}' -f $mode, ($p.ExitCode -band 0xFFFFFFFF),
(([string](Get-Content $o -Raw)) -replace '\r?\n',' ').Trim()
}

Run 'read-only' # → exit=0x00000000 out=ok
Run 'workspace-write' # → exit=0xC0000142 out=
结果（本机实测，可复现率 100%）：
代码块
read-only exit=0x00000000 out=ok
workspace-write exit=0xC0000142 out=

3、已排除项（避免重复排查）
不是 PowerShell 版本问题：cmd.exe、where.exe 同样失败；PowerShell 5.1 与 7.6.6 都失败
不是 .NET / CLR 初始化问题（5.1 曾是这个怀疑方向，但 cmd.exe 也会挂）
不是 Low 完整性级别（noli 变体仍然失败）
不是 restricting SID 列表（nosids 变体仍然失败）
不是工作区 ACL / 路径 / 当前目录（在没有任何 DSH ACE 与标签的全新空目录、以及把 cwd 设为 C:\Windows 的情况下同样失败）
不是 PATH / 沙箱 runner 本身（同一 runner 在 read-only 模式下正常）
不是 denied 类拒绝（工具元数据为 denied: false）

[Ethan-H1K]

补帖：补上最关键的两块证据（A/B 对照 + 修复 diff）以及环境与验证方法，维护者可以直接定位到那一行。

根因（一行）

模块：@deepseek-ai/dsh-sandbox-windows-acl → AclSandbox.init()

js

const logonSid = findLogonSid(api, currentToken);
restrictedToken = createRestrictedToken(api, currentToken, logonSid,
    [this.writeSidPtr, this.tempWriteSidPtr].filter((sid) => sid !== void 0),
    { world: worldSid }, this.mode);
restrictTokenIntegrity(api, restrictedToken, lowLabelSid);
setTokenDefaultDaclGrant(api, restrictedToken,
    this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);   // <-- 问题行

workspace-write 下 Default DACL 追加的 trustee 是 capability SID（S-1-4-…）；read-only 走的是 worldSid（Everyone）。

A/B 对照（同一个内置 runner、同一条命令行，只改一个变量）

变体 | restricting SID 列表 | Default DACL 追加的 trustee | 降 Low 完整性 | 结果 -- | -- | -- | -- | -- baseline（现状） | logon + Everyone + wsSid + tempSid | capability SID | 是 | ❌ 0xC0000142 nosids | logon + Everyone | capability SID | 是 | ❌ 0xC0000142 noli | logon + Everyone + wsSid + tempSid | capability SID | 否 | ❌ 0xC0000142 dacl | 不变 | Everyone | 是 | ✅ 0x00000000，cmd 输出 ok daclboth | 不变 | capability SID + Everyone | 是 | ✅ 0x00000000 dacl + PowerShell 7.6.6 | 不变 | Everyone | 是 | ✅ 0x00000000，输出 ps7-ok

修复后如何验证

1. 跑上面 2.2 的最小复现脚本：workspace-write 应返回 0x00000000、out=ok；
2. 界面内用 workspace-write 会话执行 cmd /c echo hi 与 pwsh -NoLogo -Command '$PSVersionTable.PSVersion'；
3. 回归确认隔离仍生效：在 workspace-write 会话里写工作区之外的文件，应当被拒绝。

想请你们确认一个问题

createRestrictedToken() 上方的注释写着该实现 “verified on Win11 26200”。本机是 Win10 22H2 (19045)，100% 复现。

想确认：在 Win11 上是否复现？ 如果不复现，说明这是 Win10 上 Default DACL / 受限令牌的行为差异，也解释了为什么这个缺陷没有在你们的验证环境里暴露。

---

English summary

On Windows 10 22H2 (19045), under the workspace-write ACL sandbox every child process dies with 0xC0000142 (STATUS_DLL_INIT_FAILED) and produces no output — including cmd.exe, where.exe, Windows PowerShell 5.1 and PowerShell 7.6.6. The read-only sandbox works normally on the same machine.

Root cause: AclSandbox.init() sets the restricted token's Default DACL to a trustee that is a capability SID (S-1-4-…), i.e. setTokenDefaultDaclGrant(api, restrictedToken, this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid). Because the default DACL applies to every kernel object the token creates without an explicit security descriptor, components involved in early process initialization are denied access and DLL initialization fails.

Evidence: an A/B run of the shipped runner changing only that one variable — with worldSid (Everybody), or capability SID plus worldSid — returns 0x00000000 and both cmd.exe and PowerShell 7.6.6 work. Removing the capability SIDs from the restricting list, or skipping the Low-integrity step, does not help.

Suggested fix: add worldSid to the default DACL in addition to the capability SID (or use worldSid alone).

[maozhuoshushu]

Cross-referencing a second, independent root cause for this same exit code: #8721 (packaged desktop / GUI-subsystem host: the process that creates the restricted child must itself own a console; the mediator interpreter comes from windowsAclRunnerInvocation() in dsh-sandbox-local/lib/index.js:539-553, and dsh-sandbox-windows-acl/lib/runner.js:157 is the sandbox.spawn call).

The two are not mutually exclusive, and this thread currently has the upvotes — so a "fixed the DACL, still broken for some users" report is likely to arrive unless both are checked:

	Default DACL = capability SID (this thread)	Default DACL = worldSid (fixed)
mediator = GUI-subsystem image (ELECTRON_RUN_AS_NODE=1)	fails	fails (console-ownership)
mediator = console-subsystem node.exe	fails	works

A quick discriminator, using the harness you already posted here: if the failure survives the worldSid change when the mediator is the packaged app image (ELECTRON_RUN_AS_NODE=1), but disappears when the same runner is launched through a console-subsystem node.exe, the remaining cell is the console-ownership one. Conversely, if node.exe as mediator still fails, the Default DACL is the whole explanation.

Independent reproduction of the console-ownership case + workaround: Astral-Dream/dsh-windows-sandbox-0xC0000142-workaround#1 · CI-side occurrence of this exit code: sjh9714/dsh-win32#91

[maozhuoshushu]

Thanks for the detailed write-up — the A/B table and the "问 Win11 是否复现" question are exactly the right things to ask. I ran the same experiment on Windows 11 26200 (registry: Windows 10 Pro, DisplayVersion 25H2, CurrentBuild 26200, UBR 8524; elevated administrator token), instantiating the shipped AclSandbox (@deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2) directly and changing only the one variable, as you did.

Result: I cannot reproduce the capability-SID failure on 26200

Same built-in runner, same command line, only the mode changed:

Trial	init	cmd.exe (pipe)	cmd.exe (inherit)
read-only (Everyone)	ok	0x00000000 SANDBOX_SHELL_CHECK	0x00000000
workspace-write (capability SID), temp=null	ok	0x00000000 SANDBOX_SHELL_CHECK	0x00000000
workspace-write (capability SID), temp=yes	ok	0x00000000 SANDBOX_SHELL_CHECK	0x00000000

The restriction was genuinely in force, so this is not a "sandbox silently did nothing" artifact:

Probe	read-only	w-write (temp=null)	w-write (temp=yes)
write workspace	EPERM (not granted — correct)	OK	OK
write C:\Windows\Temp	EPERM	EPERM	EPERM
read System32\kernel32.dll	OK (836208 B)	OK	OK

Why "Default DACL = capability SID" is not a substitution

setTokenDefaultDaclGrant() merges rather than replaces — types-DxezulnA.js:806 calls SetEntriesInAclW(1, buildExplicitAccess(sidPtr, 1, FILE_ALL_ACCESS), currentDacl, newDaclSlot). Dumping the restricted child's own TokenDefaultDacl on this machine (4 ACEs in every case):

ambient (unrestricted) : 0x10000000 S-1-5-32-544 · 0x10000000 S-1-5-18 · 0xA0000000 S-1-5-5-0-900990

read-only              : 0x001F01FF S-1-1-0                 + those three, all present
workspace-write temp=null: 0x001F01FF S-1-4-801027725-1051640001 + those three, all present
workspace-write temp=yes : 0x001F01FF S-1-4-646860448-1008314170-1 + those three, all present

So the capability SID is added on top of S-1-5-18 (SYSTEM) and S-1-5-32-544 (Administrators), and both are groups the restricted token still holds and that are absent from the restricting list — which is why the default-DACL access check passes on this machine. That makes "change it to worldSid" an empirical workaround for your box rather than the single correct fix.

The most likely difference between our machines: mine is an elevated administrator token, whose ambient Default DACL carries SYSTEM + Administrators. If your failing token's ambient Default DACL lacks both, appending a capability SID cannot rescue it and only an Everyone ACE would — which would explain your dacl variant succeeding.

One decisive run, if you are willing

On the failing Win10 19045 box, in read-only mode, print the restricted child's Default DACL:

$env:ELECTRON_RUN_AS_NODE='1'
Start-Process <app-image> -ArgumentList '--expose-internals "<…>\dsh-sandbox-windows-acl\lib\runner.js" --workspace <ws> --temp <tmp> --mode read-only -- <node.exe> <dump-default-dacl.mjs>'

• If S-1-5-18 / S-1-5-32-544 are absent from that DACL → root cause confirmed as the ambient Default DACL, and the correct fix is to add Everyone (your dacl variant), not to swap the trustee.
• If they are present → it is not the Default DACL, and the remaining variables are elevation (is your shell running elevated?), a GPO/policy override of the Default DACL, or a Win10-vs-Win11 kernel difference in how the DACL is applied during process creation.

I left the probe sources in #8721, and both threads now cross-reference each other. Either way, please keep the worldSid/Everyone addition — it is strictly safer and clearly fixes your machine.

[maozhuoshushu]

直接回答你的问题，并且要分两层说，因为第一层只是"是/否"，第二层才是真正能解释"为什么你们的验证环境没暴露"的。

1. Win11 26200 上是否复现？

在我这份条件下不复现。 我在 Windows 11 26200（注册表 CurrentBuild 26200 / UBR 8524，elevated 管理员）上，用随包发布的 @deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2，按你的实验方式直接实例化 AclSandbox：

沙箱模式	结果
read-only	✅ 0x00000000
workspace-write（capability SID，tempWriteSid=null）	✅ 0x00000000
workspace-write（带 temp SID）	✅ 0x00000000

三档全部成功、输出 SANDBOX_SHELL_CHECK，你的 dacl / daclboth 那一格在本机是常态而不是特例。令牌确实是被限制的（read-only 下写工作区 ❌ EPERM、写 C:\Windows\Temp ❌ EPERM、读 system32 ✅），所以不是"沙箱没生效所以看起来正常"。

我还把受限子进程自己的 Default DACL 打印出来（每档都是 4 条 ACE，"capability SID" 是追加而不是替换，这一点和你对 SetEntriesInAclW(1, …, currentDacl, newDaclSlot) 合并语义的判断一致）：

ambient   : 0x10000000 S-1-5-32-544 · 0x10000000 S-1-5-18 · 0xA0000000 S-1-5-5-0-900990
read-only : 0x001F01FF S-1-1-0 (Everyone)                       + 上面三条全在
workspace : 0x001F01FF S-1-4-801027725-1051640001 (workspace)   + 上面三条全在
w-write+t : 0x001F01FF S-1-4-646860448-1008314170-1 (temp)      + 上面三条全在

在 26200 上无论加不加 capability SID，S-1-5-18(SYSTEM) 与 S-1-5-32-544(Administrators) 都还在、都不在 restricting 列表里，所以默认 DACL 的访问检查照样通过。这大概就是你那条因果链在 26200 不成立的原因——它是不是 19045 特有的，我还不能断定，但我这份数据不能支持"capability SID 一律致命"。

给你一条决定性判据，比我复述结论有用：在你那台失败机器上，跑 read-only 模式的受限子进程，打印它自己的 Default DACL——

• 如果 S-1-5-18 / S-1-5-32-544 缺失 ⇒ 根因确实在你那条线上（ambient Default DACL 里没有可用 trustee），正解就是补 worldSid；
• 如果存在 ⇒ 缺失的不是 trustee，那就得往"是否 elevated / 组策略覆盖 / 19045 与 26200 的令牌行为差异"查。

（打印脚本我可以贴，或者你自己补两行 GetTokenInformation(TokenDefaultDacl) 也行。）

2. 但 26200 并非"不会出 0xC0000142"——我复现了，条件是换中介

第 1 节全部是在我自己这个进程里实例化 AclSandbox 得出的，也就是说中介是 CLI 那个 node.exe。把中介换成打包桌面端的 GUI 子系统镜像后，同一个 26200 机器上：

中介解释器	read-only	workspace-write	workspace-write + temp SID
GUI 子系统镜像（DeepSeek Harness.exe + ELECTRON_RUN_AS_NODE=1）	✅ 0x00000000	❌ 0xC0000142 零输出	❌ 0xC0000142 零输出
console 子系统 node.exe	✅	✅	✅

（spawn() 每次都正常返回 pid，子进程死在 DLL 初始化期，即子进程内部 STATUS_DLL_INIT_FAILED，不是 spawn 调用失败。）

这就是我怀疑"你们的验证环境为什么没暴露"的答案，而且它和 Windows 版本无关：

失败需要两个条件同时成立 —— 中介进程没有控制台，且沙箱是 workspace-write。
如果验证环境走的是 CLI（…\resources\runtime\cli\bin\dsh.cmd），中介就是 console 子系统的 node.exe，
那条路径在 19045 和 26200 上都不会复现。

你上一轮说过 CLI 下 100% 正常、你手上的创建层用 cmd.exe 能起来——这两条正好和上表第二行吻合。而你和这个帖子的报告都发生在打包桌面端（GUI 子系统宿主）里。所以"没暴露"可能不是 Win10/Win11 差异，而是验证环境用的是 console 中介。这一条建议你们优先排查，因为它同样能解释为什么这个缺陷在 26200 的自动化验证里也藏着。

顺带两条能缩小范围的实测（同一台 26200，中介固定为 GUI 镜像，只跑 cmd.exe）：

• 在 spawn 之前调一次 AllocConsole() ⇒ workspace-write 从 ❌ 变成 ✅ 0x00000000；
• 但 read-only 加 FreeConsole() ⇒ 仍然成功。所以"必须有控制台"这个说法太简单：read-only 那条令牌路径两种控制台状态下都安全，不安全的是 workspace-write 那条。
• workspace-write 下把 tempWriteSid 传成 workspace SID ⇒ 仍失败；stdio: 'inherit' ⇒ 仍失败（把这两个变量排除掉）。

3. 最小复现脚本

probe-dacl-mediate.mjs 是中介无关的：它只负责在给定工作区里按 --mode 实例化 AclSandbox 并在里面跑 cmd.exe /c echo SANDBOX_SHELL_CHECK。换中介只要换启动它的解释器：

:: 会失败的那一行（GUI 子系统镜像当中介）
set ELECTRON_RUN_AS_NODE=1
"C:\...\DeepSeek Harness.exe" probe-dacl-mediate.mjs "D:\some\workspace"

:: 永远成功的那一行（console 子系统 node.exe 当中介）
"C:\...\dsh-primary-runtime\dependencies\node\bin\node.exe" probe-dacl-mediate.mjs "D:\some\workspace"

probe-dacl-stepwise.mjs 是第 2 节那组变体（AllocConsole / FreeConsole / tempWriteSid / stdio）。

4. 和 #8721 的关系

#8721 是"中介无控制台 + workspace-write ⇒ 0xC0000142"这条（我在那边贴了完整 2×2 和分步定位见 https://github.com/deepseek-ai/deepseek-harness/discussions/8721）。你这条是"Default DACL 的 trustee 用了 capability SID"。

我一开始把你们当成同一个缺陷的两条独立根因，现在改口：在 26200 上它们并不互相需要，而且在你的 A/B 里 worldSid 单独就能修好——所以两台机器上的触发条件很可能是不同的。如果第 1 节的判据显示你那台机器缺 S-1-5-18/S-1-5-32-544，那结论就是"同为 STATUS_DLL_INIT_FAILED，但 19045 的触发点在默认 DACL、26200 的触发点在中介控制台"，这反而更值得在注释里写清楚，免得下一个人按平台猜。

[dsh-community-assistant[bot]]

已收到这条反馈。