[Bug][Windows] workspace-write 下 restricting 列表含 1 个 S-1-4 capability SID 即致任何子进程 0xC0000142 秒退 — 最小复现与精确定位（关联 #8991）

[echo-125]

关联 #8991：同样的 workspace-write 沙箱失败。本帖补充精确定位到单个 restricting SID、可直接运行的最小复现脚本，以及"非 .NET 进程同样失败"的对照证据。

现象描述

workspace-write 档位下，agent 调用 pwsh 工具时 PTY 启动失败，UI 只显示：

PTY shell exited during startup

绕过 DSH UI、用 AclSandbox/runner API 直接测试，底层真实表现是：任何被 windows-acl runner 包装启动的子进程都在 DLL 初始化阶段立即死亡，与被启动的命令无关：

启动方式	结果
裸 node-pty 直启 pwsh（不经沙箱）	✅ 正常
runner + read-only 模式	✅ 正常输出，exit 0
runner + workspace-write + whoami	❌ exit 0xC0000142，零输出
runner + workspace-write + cmd /c echo	❌ exit 0xC0000142，零输出
runner + workspace-write + pwsh	❌ exit 0xC0000142（inherit stdio 下为 0xC000013A）

关于 #84（anywhere-labs）".NET self-contained DLL init 失败"结论的修正：纯原生的 whoami.exe、cmd.exe 同样死亡，说明问题不在 .NET，而是该受限 token 配置下任何进程都无法完成 DLL 初始化。

最小变量定位（本帖核心贡献）

直接调用 AclSandbox API（不经 DSH UI、不改任何目录 ACL），只变 restricting SID 列表一项：

• restricting list = [logon SID, Everyone]（read-only，0 个 capability SID）→ whoami 正常输出 r9000p\administrator，exit 0
• restricting list = [logon SID, Everyone, S-1-4-…]（1 个 capability SID，manageDacls: false）→ 0xC0000142 必死

即：只要 CreateRestrictedToken 的 restricting 列表包含 1 个 S-1-4-… capability SID，子进程必死——与目录 DACL 改动、Low 完整性标签、命令内容、stdio 形态（inherit/piped）均无关。workspace-write 恰好必含该 SID（workspaceWriteSid/tempWriteSid），故该档位全灭；read-only 不含，故可用。

电脑环境

• OS：Windows 10 Pro 26H1，build 28000.2704，x64（README 称在 Win11 26200 验证；[Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr #8991 为 22631——本帖是第三个不同 build 的复现）
• DSH：0.2.0-rc.2 desktop（win-x64）
• PowerShell：7.6.6（C:\Program Files\PowerShell\7\pwsh.exe）
• 安全软件：火绒（Huorong HIPS）运行中。尝试退出（托盘可退、核心服务有自我保护停不掉）前后复现结果完全一致；[Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr #8991 报告者环境无火绒同样复现 → 火绒非必要条件
• 系统机制对照：runas /trustlevel:0x20000（标准受限 token）运行 cmd 正常 → Windows 受限 token 基础机制无问题
• pwsh、ConPTY、node-pty、Electron node 模式裸测试全部正常 → 运行时自身无问题

做了哪些尝试

1. 裸 pwsh：node-pty 直接 spawn → 正常（排除 pwsh / ConPTY / node-pty）
2. 模式对照：同一 runner，read-only 正常 / workspace-write 必死
3. 换命令：whoami、cmd、pwsh 全死（排除命令与运行时特异性）
4. stdio 对照：inherit（0xC000013A）与 piped（0xC0000142）都死（排除控制台句柄因素）
5. A/B 分离：manageDacls: false（不改任何目录 DACL）仍死 → 排除目录 ACL 改动与 Low 标签传播
6. 最小化：单个 capability SID 即触发（见上）
7. 系统对照：runas /trustlevel 受限 token 正常 → 排除系统级不支持受限 token
8. 安全软件对照：尝试退出火绒后仍复现
9. 绕过：切 danger-full-access 后 pwsh 工具立即恢复（与 [Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr #8991 一致）；read-only 也可用但不可写工作区

最小复现脚本

用 DSH 自带 Electron 以 node 模式运行（不经过 DSH UI）。保存为 repro.mjs 后执行：

$env:ELECTRON_RUN_AS_NODE = '1'
& 'E:\Program Files\deepseekharness\DeepSeek Harness.exe' repro.mjs

// repro.mjs — 复现 workspace-write 受限 token 下子进程 0xC0000142
// 路径按本机 DSH 安装位置调整
import fs from 'node:fs';
import os from 'node:os';
import path from 'node:path';

const base =
  'file:///E:/Program Files/deepseekharness/resources/app.asar/dsh/node_modules/@deepseek-ai/dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js';
const mod = await import(base);
const AclSandbox = mod.t;           // minified export: t = AclSandbox
const workspaceWriteSid = mod.a;    // minified export: a = workspaceWriteSid

async function run(label, mode) {
  const ws = fs.mkdtempSync(path.join(os.tmpdir(), 'dsh-repro-ws-'));
  const opts = {
    writableDirs: [ws],
    tempDir: null,
    manageDacls: false,             // 关键：不改任何目录 ACL，只变 restricting list
    mode,
  };
  if (mode === 'workspace-write') opts.writeSid = workspaceWriteSid(ws); // +1 个 S-1-4 capability SID
  try {
    const sb = new AclSandbox(opts);
    await sb.init();
    const child = sb.spawn({ command: 'C:\\Windows\\System32\\whoami.exe', args: [] });
    const r = await child.wait();
    console.log(label, '=> exit=', r.exitCode, 'stdout=', JSON.stringify(r.stdout.toString().trim()));
    sb.dispose();
  } catch (e) {
    console.log(label, '=> THROWN:', e.message);
  }
}

await run('[read-only, 0 cap SID]', 'read-only');       // => 正常 exit 0
await run('[workspace-write, 1 cap SID]', 'workspace-write'); // => 3221225794 (0xC0000142)

本机实际输出：

[read-only, 0 cap SID] => exit= 0 stdout= "r9000p\\administrator"
[workspace-write, 1 cap SID] => exit= 3221225794 stdout= ""

期望

1. 定位 S-1-4-… capability SID 进入 restricting 列表后导致子进程 DLL 初始化失败的根因（是否为特定 build 上的 Windows 行为，或与第三方安全软件注入交互）；
2. 失败时按 runnerFailureRules 输出可读的沙箱诊断，而非裸 0xC0000142 / UI 上的 PTY shell exited during startup（与 [Bug] workspace-write sandbox: every confined pwsh command exits with 0xC0000142 (STATUS_DLL_INIT_FAILED), no stderr #8991 的诉求一致）。

[argszero]

Thank you — this is the third report of the same code on a third Windows build (#8990 26100, #8991 22631, yours 28000), and the first one that varies a single input. I took your A/B to the shipped source and it maps onto the token construction exactly.

Your isolation, against the source

packages/sandbox/sandbox-windows-acl/src/token.ts — createRestrictedToken() — assembles the restricting list literally as you measured it:

const restrictingSids = buildRestrictingSids(mode === 'read-only'
  ? [logonSid, known.world]                                    // logon SID + Everyone: 0 capability SIDs
  : [logonSid, known.world, ...writeSids])                     // + the capability SIDs

writeSids are workspaceWriteSid() (S-1-4-x-y, derived from the canonical workspace path) and, per live session, tempWriteSid() (S-1-4-x-y-1) — both two/three-subauthority capability SIDs, both only under workspace-write. read-only carries none, which is precisely your control arm. So "workspace-write 全灭 / read-only 正常" is not an incidental correlation: it is one boolean in the list assembly, and the failing mode is the one that adds a capability SID.

Two corrections to the surrounding hypotheses that the source does support:

1. The runner does not die — the confined child does. Your framing in #8991 ("the runner process itself dies at load time") is inconsistent with the backend's own failure contract: the windows-acl runner reports every runner-side failure as windows-acl-run: <detail> on stderr with exit 127 (packages/sandbox/sandbox-local/src/index.ts, RUNNER_FAILURE_RULES['windows-acl'] = [{ allowedExitCodes: [127], fatalSignatures: ['windows-acl-run: '] }]). A bare 0xC0000142 with no windows-acl-run: line means the runner itself completed normally and the child was terminated by the loader. This matters for triage: there is no runner crash to find, and the zero-stderr shape is the loader's, not a swallowed diagnostic's.

2. Why the user only ever sees the number. The same rule set is why nothing classifies it: the code is only recognized as a runner failure at exit 127, so 0xC0000142 passes through as an ordinary nonzero exit, and the renderer reports nonzero exits without erroring. On the PTY path it is worse — dsh-terminal-bash throws the fixed string PTY shell exited during startup (terminal-bash/src/index.ts:140) and the status is not in the message at all. Both of your requested outcomes (classify it, or explain it) are therefore upstream-fix shaped; a raw NTSTATUS reaching a user with no sandbox framing is the defect I would file separately from the root cause.

One thing worth knowing before the root cause is hunted

0xC0000142 is the restricted-token layer's generic early-init death, and the source records a trigger in the opposite direction from yours. From the same createRestrictedToken docstring, on why the keep-alive group exists:

The logon SID + EVERYONE keep-alive group is shared by both modes: early DLL init dies with 0xC0000142 and CNG (\Device\CNG write trustee — pwsh crashes 0xE0434352) fails without them.

So: too few entries in the restricting list kills early init, and — per your measurement — too many (a S-1-4-… capability SID) kills it as well, on the same status code. The code alone cannot say which mistake was made; the mode split is the only discriminator a user has, and it is exactly the axis you varied. That is also why I would resist naming the capability SID "the root cause" on the strength of one machine: your A/B pins where it starts (list membership, with manageDacls: false, so no DACL or label is involved), and the source shows the mechanism that reads that list is WRITE_RESTRICTED pass-2 — but which of the two is the trigger on build 28000 versus the builds where it works is a question for a machine that reproduces it.

Your whoami.exe / cmd.exe control is the most useful single line in the report, by the way: it retires the .NET self-contained story that followed the earlier threads. A pure-native process with no .NET runtime in its image dying the same way means the failure is in the token/loader interaction, not in managed code. Firewall/HIPS was already excluded by the other reporters; your pair now excludes the runtime too.

What I can offer from this side

I maintain a plugin that recognizes exactly this failure family at the tool-result seam (@argszero/cordis-plugin-sandbox-grant-advisor) — it is a stopgap for the second half of your "期望": the recognition rides on kind: 'foreground' plus a 32-bit integer exitCode, so a command that merely prints the number cannot fake it, and it emits a durable advisory naming the mode, the two producers it currently knows, and what to check. Your report adds a third producer and, more valuable, a user-runnable discriminant — mode held constant, command and stdio varied — which the current text cannot offer. Next release carries it, with the opposite-direction trigger above stated in the body so no reader infers a cause from the code alone.

For the immediate session: read-only and danger-full-access are both consistent ways out (the latter removes the sandbox rather than fixing it), and nothing user-side repairs the token — the restricting list is assembled by the harness on every spawn. Retrying the same call cannot change the outcome.

Thanks again for doing the elimination work rather than reporting the symptom — the manageDacls: false arm is what makes this actionable.

[argszero]

Released this as @argszero/cordis-plugin-sandbox-grant-advisor@0.16.0 — the diagnosis in my earlier reply, made maintainable. This is the first report in this family whose producer we could not have measured ourselves, and the first of them that comes with a check a reader can run from inside the session, so the advisory now carries both.

What the plugin now says about your case. 0xC0000142 STATUS_DLL_INIT_FAILED, the process never reaching its entry point, under a confining mode — and the producer is the restricted token's own restricting list. The discriminator is a mode switch: hold the command and the tool fixed and change only the mode. read-only carries no capability SID (createRestrictedToken() is verbatim read-only ? [logonSid, world] : [logonSid, world, ...writeSids], and writeSids is workspaceWriteSid() + tempWriteSid(), both S-1-4-…), so the same program that dies under workspace-write starts under read-only — one setting, no debugger, no second machine.

Why the text hands that comparison over instead of naming the cause. The restricted-token layer records the opposite direction of the same code: a token built without the logon-SID + EVERYONE keep-alive pair also dies in early DLL init with exactly 0xC0000142 (and pwsh earlier still, in its CNG path, as 0xE0434352). Too few entries in the restricting list and too many land on the same value, so the status cannot name its own direction — and it cannot say "sandbox" either. A plugin that asserted a producer on this code would be a confident wrong cause for every reader whose token was instead built wrong the other way, which is why it hands over the one comparison the code does not already give you.

Two corrections your control arm supplies, both now in the advisory:

• .NET is out. Pure-native whoami.exe and cmd.exe die exactly as pwsh does, so the "self-contained .NET runtime" cause the earlier reports converged on is retired by that measurement rather than by an argument of ours.
• The token is not the discriminator as a whole — one member of it is. [BUG] dsh桌面版下面无害命令(pwsh/cmd echo在内)都报错 `0xC0000142`(STATUS_DLL_INIT_FAILED) #8208 compared whoami /groups and /priv from children of a working node host and of a failing Electron host and found them identical, which rules out groups, privileges and integrity level; it says nothing about which SIDs the token was restricted to, which is the member your report changes. The advisory now states that distinction explicitly instead of saying "the token is not the discriminator" flatly.

Also corrected in the same release, because a reader who sees a bare 0xC0000142 asks why they got only a number: RUNNER_FAILURE_RULES['windows-acl'] admits exit 127 with the windows-acl-run: signature only (and classifyRunnerFailure skips every other code before it looks at stderr), so the code passes through as an ordinary nonzero exit which the renderer reports without marking the result an error. That is not a swallowed sandbox diagnostic — it never enters the classification at all. The persistent-PTY path is thinner still: the shell layer throws a fixed sentence with no status in it, so there the mode split is the only evidence there is.

Where this sits in the family. native-init now enumerates three measured producers — an MSYS2 / Git-Bash program (#7877), the sandbox runner's own console (a GUI-subsystem host image, or a real node.exe spawned with DETACHED_PROCESS; #8193, #8208), and the restricting list (#9186) — each with the check that separates it, plus the stop instruction and the honest boundary that says what the list does not have. 0.16.0 also folds in #8990 and #8991 (the same code on two more builds, where no comparison was possible from the reporter's side) and #9170 (the desktop-fails / dsh web-works split measured from the user's own side).

Package: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor — npm i @argszero/cordis-plugin-sandbox-grant-advisor, mounted through its dsh.bundle.patch. 131 tests, the mutation harness reports every arm CAUGHT with none silent, and all five admitted peer lines were re-probed after this change.

[echo-125]

感谢两条详细的回复——runner 正常完成而死的是被限制的子进程、以及裸 0xC0000142 为何完全进不了失败分类链，这两处修正都收到；read-only / danger-full-access 之外用户侧无从修复这一点，也和我们的判断一致。

补一点可能有用的信息：我这台机器（build 28000）是稳定复现机——单 capability SID 脚本 100% 必现 0xC0000142，read-only 对照 100% 正常，且结果不受火绒运行状态影响。如果后续需要在真机上验证"restricting list 过多"在该 build 上的具体触发机制（跑额外对照实验、看 advisor 插件的输出、或任何你设计的判据），我可以直接配合执行。

官方修复前我这边继续用 danger-full-access 绕过。谢谢你的排查工作和插件。