Windows 下 workspace-write 沙箱让所有 shell 子进程以 0xC0000142（STATUS_DLL_INIT_FAILED）失败：受限令牌默认 DACL 只并入 capability SID 所致

[xushaojun1108]

dsh-issue-反馈短版.md
dsh-issue-windows-sandbox-0xC0000142.md

[xushaojun1108]

环境：Windows 11（build 26300，x64）；DSH 桌面端 0.2.1-rc.3；@deepseek-ai/dsh-sandbox-windows-acl 0.2.1-rc.3。

现象：权限切到「工作区内修改」（workspace-write）后，shell 完全不可用——ops_bash 与 pwsh 执行任何命令都返回 (no output) + [exit code: 3221225794]（3221225794 = 0xC0000142 = STATUS_DLL_INIT_FAILED），命令根本没跑起来。切到「仅可查看」或「完全权限」，同样的命令立刻正常。

独立复现：直接用 Electron-as-node 跑 app.asar 里的 @deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js，--mode workspace-write 必失败、--mode read-only 正常；换工作区目录、换卷（C:/D:/E:）、换临时目录、换 cwd 都一样。cmd.exe / 随包 bash / pwsh 三个都失败，不受限跑同样三个都正常。

根因：该包 AclSandbox.init() 里

setTokenDefaultDaclGrant(api, restrictedToken,
  this.tempWriteSidPtr ?? this.writeSidPtr ?? worldSid);

在 workspace-write 下 this.writeSidPtr 是 capability SID（S-1-4-…），于是受限令牌的默认 DACL 只多出一条 capability SID 的 GA ACE。但受限令牌是 LUA_TOKEN | WRITE_RESTRICTED（Administrators 变 deny-only、又不带 SYSTEM），子进程新建对象后要再打开它们时，读侧检查用的是普通 SID；只要父进程令牌的默认 DACL 里没有子令牌可用的普通 SID（本机实测父令牌为 D:(A;;GA;;;BA)(A;;GA;;;SY)(A;;GXGR;;;S-1-5-5-0-<logon>)，既无用户 SID 也无 Everyone），子进程在 DLL 初始化阶段就死成 0xC0000142。read-only 没有 write SID，?? 落到 worldSid（Everyone），所以不受影响——同一份代码两种模式并不一致。

变量隔离（运行期钩子改行为，不动文件本体，全部 workspace-write + cmd /c exit 42）：

变量	结果
基线	3221225794
restricting 列表去掉 capability SID	3221225794
跳过 restrictTokenIntegrity（不降 Low）	3221225794
默认 DACL 的 ACE 换成 Everyone	42 ✓
默认 DACL 的 ACE 换成 logonSid	42 ✓
保留 capability ACE 再追加 Everyone	42 ✓

修复建议：setTokenDefaultDaclGrant 里带上一条子令牌可用的普通 SID（Everyone，或调用方用户 SID），capability SID 继续留在 restricting 列表里做写限制。本机把那一行换成 worldSid 后，workspace-write 下 ops_bash/pwsh 恢复正常，工作区外写仍被拒（隔离没变松）。另建议把「子进程创建即 0xC0000142」这类失败在日志里打出可诊断字样

[2424830124]

补充一份独立复现 + 一个能解释「为什么有人遇不到」的变量，并确认：@deepseek-ai/dsh-sandbox-windows-acl 0.2.1-rc.4（DSH Desktop 2.0.21-next）仍未修复。

环境：Windows 11 22631 x64；DSH Desktop 2.0.21-next；dsh-sandbox-windows-acl 0.2.1-rc.4；实际解释器 powershell.exe 5.1.22621.6931（本机未装 pwsh 7）。现象一致：workspace-write 下 pwsh 一律 [exit code: 3221225794] 且无任何输出；danger-full-access 正常。

观察 1：这条进程链上没有控制台

• DSH NEXT.exe（pid 35260，GUI 子系统）无控制台：从子 shell 里 FreeConsole() 后 AttachConsole(35260) → FALSE，GetLastError = 6（ERROR_INVALID_HANDLE）。
• 全权限模式下 powershell 子进程的 GetConsoleProcessList 只有它自己（count = 1，GetConsoleWindow 非 0）→ 它是自己新建的控制台，也就是说它的父 runner 同样没有控制台。
• 进程树：DSH NEXT.exe(35260) → app.asar/lib/host.js(31172) → dsh-subprocess-local/lib/runner.js(36312) → powershell.exe。

观察 2：把 runner 抽出 asar 做对照，唯一变量是「链路上有没有普通令牌进程先建好控制台」

同一命令（powershell.exe -NoProfile -Command "Write-Output CONFINED-OK"）、同一 --workspace / --temp、同一套令牌构造：

条件	结果
A. 父进程有控制台，直接跑 runner	CONFINED-OK，exit 0
B. 父进程无控制台，但链路里普通令牌 cmd 先建控制台（Invoke-CimMethod Win32_Process Create）	CONFINED-OK，exit 0
C. detached runner，整条链无控制台	3221225794

即：受限子进程只要能继承一个已存在的控制台就能活；一旦它必须自己创建控制台，就在 DLL 初始化阶段死掉。

这与你们定位的 DACL 根因完全相容：受限令牌默认 DACL 里没有子令牌可用的普通 SID，任何「受限进程自己创建、然后再打开」的内核对象都会失败——控制台 / conhost 只是第一个撞上的；而继承一个父进程已建好的控制台不需要新建对象，也就不撞。

为什么不是每个人都遇到

dsh-sandbox-windows-acl 的 README「已验证边界」写的是「子进程共享宿主控制台，基于管道的 stdio 重定向不受影响」——设计前提是受限子进程继承宿主控制台。但 DSH 的 subprocess runner 在 Windows 上自身不带控制台，于是 workspace-write 的 powershell 成了链上第一个「需要控制台且只能自建」的进程，必然踩中。

修复建议（与上面那条互补）

1. 主修：setTokenDefaultDaclGrant 带上 Everyone 或调用方用户 SID（你们已验证），capability SID 继续留在 restricting 列表里做写限制，隔离不变松。
2. 兜底：runner 在 spawn 受限子进程前，若自身无控制台先 AllocConsole()（此时它还是普通令牌，必然成功），让受限子进程继承——这同时让 README 里「子进程共享宿主控制台」的前提真正成立。
3. 可诊断性：dsh-sandbox-local 启动时的功能探针（cmd /c exit 0 包在 runner 里跑）应当把 0xC0000142 判为后端不可用并返回 SANDBOX_UNAVAILABLE，而不是把裸退出码透给用户。现在用户只看到一个没有任何线索的数字。