Repository navigation
Replies: 1 comment 2 replies
|
Your reading matches two places in the code. There is also a one-step experiment that separates it from the other causes.
The experiment: launch the desktop from an existing console (cmd or PowerShell) instead of Explorer, then run one confined One more that applies only to a particular account, and is easy to rule in or out: if the process runs as the built-in Administrator (SID ending What I did not verify: whether your Electron host really has no console in the launch shape you used, and what Windows does for the host's own children when it has none. Source read at |
|
Thanks, this is a very useful breakdown. Here is what I can settle from the machine that produced the report, with the evidence level marked. Short version: your candidate #3 does not hold on this box, and the failure I can still reproduce lives one generation deeper than the original report. Account / build (measured)So the precondition for your #3 is present (SID #3 (LUA_TOKEN => "cannot start any process") is falsified hereInside the confined sandbox shell - i.e. under the restricted token, not elevated - I can start processes:
If What is still broken: second-generation spawns"Generation 1" = the confined shell -> a child. "Generation 2" = that child -> its own child.
Two honest limitations:
What the working configuration actually looks like (supports #1, but not as stated)Before the workaround, every confined launch failed with That points at the variable being narrower than "the host has no console": a console must exist in the ancestry at the moment the confined child is created, and only the process owning the token can provide it. #1 is consistent with that, but your experiment as written would only test inheritance from the host, which my data suggests is not the whole story. Questions
|
|
Thanks — your reading is right on both counts, and I can now close the two gaps you flagged ("what I did not verify") plus answer your three questions with measurements instead of readings. A. Version boundary you named is confirmed from published artifacts
So the crate you described matches the bytes. (I could not resolve the short SHA B. Answering Q1: the default path never asks for
|
| child stdio | parent console | exit |
|---|---|---|
| no std handles | absent | 0xC0000142 |
inheritable pipes + STARTF_USESTDHANDLES |
absent | 0xC0000142 |
NUL handles + STARTF_USESTDHANDLES |
absent | 0xC0000142 |
non-inheritable pipes + STARTF_USESTDHANDLES |
absent | 0xC0000142 |
handle table inherited, no STARTF_USESTDHANDLES |
absent | 0xC0000142 |
| none / pipes | present | runs |
So for generation 2 the candidates are (i) the intermediate process drops the console in its own launch path — PowerShell Start-Process -Wait goes through the shell (UseShellExecute), which is a separate, console-less launch, and node's pipe spawns may add flags — or (ii) the README:189 "tree carrying another sandbox's package SID" shape.
These separate cheaply without a checkout: from inside the confined shell, call CreateProcessAsUserW yourself on the inherited token with STARTF_USESTDHANDLES and no creation flags. If that survives, the sandbox is fine and generation 2 is dying in the shell/Start-Process path; if it also dies, it is the package-SID tree case. I can run this on my box and report the cell, if that is useful to you.
D. Answering Q3: the real NTSTATUS is available
GetExitCodeProcess on the confined child returns 3221225794 (0xC0000142) — that is how the cells above are measured, so the code is not lost, only unmapped in the PowerShell shape. Start-Process -Wait throwing Access is denied is a PowerShell-layer artifact (it tries to open the child with rights the restricted token lacks), not a spawn denial; and UseShellExecute=true hanging even for cmd /c exit 5 is the shell hand-off, not the sandbox.
That is also why layer 3 of the patch prints one stderr line when the mirrored exit code equals STATUS_DLL_INIT_FAILED, including console presence — so the next reporter gets a real code plus a pointer instead of empty output.
E. Cross matrix (the "one-step experiment", in a controlled harness)
| cell | parent console | restricting list has keep-alive | child exit |
|---|---|---|---|
| C1 | present | yes | 0x0 |
| C2 | present | no | 0xC0000142 |
| A1 | absent | yes | 0xC0000142 |
| A2 | absent → AllocConsole() in the runner |
yes | 0x0 |
| B1 | absent → AllocConsole() |
no | 0xC0000142 |
| B2 | absent | no | 0xC0000142 |
Also measured on the token side (upstream parameters, 8 reps): logon SID + Everyone → runs; logon only → 0xC0000142; Everyone only → 0xC0000142; empty → 0xC0000142. Independent of Low integrity and of 0x8/0xD.
Rejected alternatives, all measured: CREATE_NEW_CONSOLE on the child → still 0xC0000142; CREATE_NO_WINDOW on the child → same; wrapper process allocating first → no help; allocating in the Electron main process → works but puts a console window on the user's desktop.
F. Limits
One machine (Windows 10 19045, single account, one Electron build, built-in Administrator). The "no console → 0xC0000142" link is measured, not explained at the loader level — no debugger was attached to the dying child. I did not test whether a capability SID in the restricting list lacks read access to System32; that is a different layer and both could be real.
Patch (git diff, +56 lines, applies to master@f3803c9)
# Draft patch (NOT applied): dsh-sandbox-windows-acl -- let the runner own a console
#
# Target repo: github.com/deepseek-ai/deepseek-harness (public)
# Target branch: master
# Baseline: f3803c96974ad4a94195fb97e5c637e9c2a3afe3 (release 0.2.2-alpha.2)
# Files: packages/sandbox/sandbox-windows-acl/src/runner.ts (2 hunks)
# packages/sandbox/sandbox-windows-acl/src/ffi.ts (2 hunks)
# Size: +56 lines, no deletions
#
# Generated by git diff (not hand-written). Verified with: git apply --check -p1 (exit 0).
# Apply from the repository root: git apply -p1 runner-ensure-console-src.patch
#
# Scope: only whether the runner owns a console, plus human-readable exit-code
# diagnostics. No token, ACL, SID or allowlist change.
# Constraint discovered while retargeting: extendWin32ProcessBindings exposes the
# kernel32 and advapi32 handles only, so ShowWindow loads user32 through
# koffi.load('user32.dll') inside the binding table.
diff --git a/packages/sandbox/sandbox-windows-acl/src/ffi.ts b/packages/sandbox/sandbox-windows-acl/src/ffi.ts
index 5ef39a4..95a608d 100644
--- a/packages/sandbox/sandbox-windows-acl/src/ffi.ts
+++ b/packages/sandbox/sandbox-windows-acl/src/ffi.ts
@@ -84,6 +84,9 @@ export interface Win32Bindings extends Win32ProcessBindings {
getTempPathW(length: number, buffer: Buffer): number
setEnvironmentVariableW(name: string, value: string): number
setConsoleCtrlHandler(handler: null, add: number): number
+ getConsoleWindow(): NativePtr | null
+ allocConsole(): number
+ showWindow(window: NativePtr, command: number): number
createFileW(
fileName: string,
desiredAccess: number,
@@ -265,6 +268,15 @@ function bindings(): Win32Bindings {
getTempPathW: bind(kernel32, 'GetTempPathW', 'uint32', ['uint32', PVOID]),
setEnvironmentVariableW: bind(kernel32, 'SetEnvironmentVariableW', 'int', ['str16', 'str16']),
setConsoleCtrlHandler: bind(kernel32, 'SetConsoleCtrlHandler', 'int', [PVOID, 'int']),
+ // Console presence. A GUI-subsystem parent (the desktop app launches the
+ // runner through process.execPath, i.e. the Electron image) owns no console,
+ // so a console-subsystem grandchild created under the restricted token
+ // finishes loader initialization without one and dies with 0xC0000142
+ // (STATUS_DLL_INIT_FAILED). user32 is not part of the shared process binding
+ // table, so it is loaded on demand here.
+ getConsoleWindow: bind(kernel32, 'GetConsoleWindow', PVOID, []),
+ allocConsole: bind(kernel32, 'AllocConsole', 'int', []),
+ showWindow: bind(koffi.load('user32.dll'), 'ShowWindow', 'int', [PVOID, 'int']),
createFileW: bind(kernel32, 'CreateFileW', PVOID, [
'str16', 'uint32', 'uint32', PVOID, 'uint32', 'uint32', PVOID,
]),
diff --git a/packages/sandbox/sandbox-windows-acl/src/runner.ts b/packages/sandbox/sandbox-windows-acl/src/runner.ts
index 8c67378..f5f3c55 100644
--- a/packages/sandbox/sandbox-windows-acl/src/runner.ts
+++ b/packages/sandbox/sandbox-windows-acl/src/runner.ts
@@ -49,6 +49,7 @@ import { closeSync, existsSync, mkdtempSync, rmSync, statSync } from 'node:fs'
import { join } from 'node:path'
import { win32 } from './ffi.ts'
+import type { Win32Bindings } from './ffi.ts'
import { AclSandbox, assertTempRootOutsideWorkspace } from './index.ts'
import { tempWriteSid, workspaceWriteSid } from './workspace-sid.ts'
@@ -113,6 +114,38 @@ function requireDirectory(label: string, path: string): void {
}
}
+/**
+ * Exit code the Windows loader produces when a console-subsystem child cannot
+ * finish DLL initialization (STATUS_DLL_INIT_FAILED).
+ */
+const STATUS_DLL_INIT_FAILED = 3221225794
+
+/**
+ * Give THIS runner a console before it spawns restricted children.
+ *
+ * The runner is launched through `process.execPath`; in the desktop app that is
+ * the Electron GUI image, which owns no console. A GUI-subsystem parent cannot
+ * donate a console, so the console-subsystem grandchild created with
+ * `CreateProcessAsUserW` reaches the end of loader initialization without one
+ * and dies with `0xC0000142`. Allocating the console inside the runner is the
+ * only variant that was measured to work (2026-10-29): a wrapper process cannot
+ * donate its console to a GUI child, and `CREATE_NEW_CONSOLE` /
+ * `CREATE_NO_WINDOW` on the child still die under the restricted token.
+ *
+ * Failure is non-fatal on purpose: a configuration without a console behaves
+ * exactly as it does today, so this can never regress a working setup.
+ * @param api - active ACL/token binding table.
+ * @returns whether a console existed before, and whether one is usable now.
+ */
+function createRunnerConsole(api: Win32Bindings): { hadConsole: boolean; ready: boolean } {
+ const hadConsole = api.getConsoleWindow() !== null
+ if (!hadConsole) api.allocConsole()
+ const window = api.getConsoleWindow()
+ // SW_HIDE (0): the console is an implementation detail, never a UI surface.
+ if (window !== null) api.showWindow(window, 0)
+ return { hadConsole, ready: window !== null }
+}
+
async function main(): Promise<number> {
const parsed = parseArgs(process.argv.slice(2))
// Both directories are validated in both modes: a provider bug that passes
@@ -138,6 +171,12 @@ async function main(): Promise<number> {
if (api.setConsoleCtrlHandler(null, 1) === 0) {
fail(`SetConsoleCtrlHandler failed (Win32 ${api.getLastError()})`)
}
+ const consoleState = createRunnerConsole(api)
+ if (!consoleState.ready) {
+ process.stderr.write(
+ `${RUNNER_SIGNATURE}: warning: no console available (hadConsole=${consoleState.hadConsole}); console-subsystem children may exit with 0xC0000142\n`,
+ )
+ }
let ownedTempDir: string | undefined
let sandbox: AclSandbox | undefined
@@ -187,6 +226,11 @@ async function main(): Promise<number> {
})
if (process.env[SUBPROCESS_CONTROL_ENV] === 'pipe') closeSync(SUBPROCESS_CONTROL_FD)
const result = await child.wait()
+ if (result.exitCode === STATUS_DLL_INIT_FAILED) {
+ process.stderr.write(
+ `${RUNNER_SIGNATURE}: child exited with 0xC0000142 (STATUS_DLL_INIT_FAILED); console=${consoleState.ready ? 'present' : 'absent'}; hint: see README "Console isolation is unavailable"\n`,
+ )
+ }
return result.exitCode
} finally {
// Cleanup failures must not mask the child's exit code: report and keep going.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Summary
On Windows,
@deepseek-ai/dsh-sandbox-windows-aclspawns its restricted child withCreateProcessAsUserW. The child is a console-subsystem process. When the process that creates it owns no console, the child cannot finish loader initialization and dies beforemain():The desktop app launches the runner through
process.execPath— the Electron GUI binary — which owns no console. Result: thepwshtool never works in the default sandbox mode, whiledanger-full-accessworks (it bypasses the sandbox entirely), so the failure looks like "the sandboxed tool is broken" rather than "the sandbox runner needs a console".Two mechanisms produce this same exit code and they are independent — see the cross matrix below. One is this console absence; the other is a restricting list missing the keep-alive group, already documented in the package README.
Environment
0.2.1-rc.3(DeepSeek Harness.exeFileVersion),resources/app.asar182,434,783 B@deepseek-ai/dsh-sandbox-local→windows-aclrunner;dsh-sandbox-windows-acl;dsh-win32-process(koffi 3.1.1)Root cause
dsh-sandbox-locallaunches the runner as[process.execPath, runner.js], i.e. the Electron binary withELECTRON_RUN_AS_NODE=1.process.execPathfor the desktop app is a GUI-subsystem executable: the process has no console (GetConsoleWindow() === NULL,GetConsoleCP() === 0).The runner then creates a
WRITE_RESTRICTED+ Low-integrity token and callsCreateProcessAsUserWfor the console-subsystem child. A console-subsystem child of a console-less parent would normally allocate a fresh console itself, but the Low-integrity restricted token cannot — so the child dies in loader initialization beforemain(), surfacing only as0xC0000142.The keep-alive group (logon SID + Everyone) is necessary but not sufficient: without it early DLL init dies (and CNG crashes
pwshwith0xE0434352when it is absent at runtime); with it, the child still needs a console it can share with its parent. The README documents this as "console isolation is unavailable — children share the host console", but the shipped desktop host has no console at all, so there is nothing to share.Verified facts that narrow it down — each measured, not inferred:
whoami /all: same 60 groups, High mandatory level in both parents)nodewith the full Electron env still succeeds)GetConsoleWindow() != NULL→ works,== NULL→0xC0000142CREATE_NO_WINDOW:packages/subprocess/win32-process/src/process.ts:232and:455set onlySTARTF_USESTDHANDLES | STARTF_USESHOWWINDOWwithwShowWindow: SW_HIDE; the only creation flags areCREATE_SUSPENDED/CREATE_UNICODE_ENVIRONMENT(:542,:567). The file states the intent at:454: "Preserve console inheritance: CREATE_NO_WINDOW can fail restricted-token DLL initialization."LUA_TOKENand the built-in Administrator are not involved on current builds: local0.2.1-rc.3app.asar callscreateRestrictedToken(currentToken, 13, …)=0xD(includesLUA_TOKEN), while npm0.2.2-alpha.2(lib/types-DFdfvhLN.js) calls it with9=0x9, andmaster@f3803c9src/token.ts:232passesDISABLE_MAX_PRIVILEGE | WRITE_RESTRICTEDwith no-500branch anywhere. Consistent with that, processes do start inside the confined shell on the affected account.Evidence: parent console (all reproduced locally; runner binary unchanged between rows)
GetConsoleWindow/GetConsoleCP)node.exefrom a consoleokDeepSeek Harness.exe(ELECTRON_RUN_AS_NODE=1), the real host path0xC0000142node.exespawned withdetached: true(DETACHED_PROCESS⇒ no console)0xC0000142node.exestarted withwindowsHide: trueAllocConsole()in the runner beforesandbox.spawn()okTwo qualifications on those rows, so the numbers are not over-read:
windowsHidehides the window; it says nothing about how the confined child is created.DETACHED_PROCESS(0x8) on the child returned 0 but lost all output capture, so it is retracted: "exit 0 with no output" cannot be distinguished from "the command never ran".Child creation flags tested separately (console-less parent):
CREATE_NEW_CONSOLE(0x10) → still0xC0000142, consistent with the README's known limitation.Evidence: restricting list (the second, independent mechanism)
Bisect with all other factors held (Low integrity + default DACL, console-less parent):
[logonsid, EVERYONE, workspaceSid, tempSid][]/[logonsid]/[EVERYONE]/[workspaceSid]0xC0000142Refined on the token side with the upstream parameters and a console present (8 repetitions per cell):
0xC00001420xC00001420xC0000142So both sides of the keep-alive group are required. Earlier notes claimed "
LUA_TOKEN/ the built-in Administrator explains the-500failures"; that does not reproduce on0.2.1-rc.3here (see the token bullet above).Evidence: stdio is not the variable
Measured with creator, token and console state fixed, varying only the child stdio shape (8 repetitions per cell; the child runs
exit 7, so "survived" cannot be confused with "silently did nothing"):0xC0000142STARTF_USESTDHANDLES0xC0000142NULhandles +STARTF_USESTDHANDLES0xC0000142STARTF_USESTDHANDLES0xC0000142STARTF_USESTDHANDLES0xC0000142This rules out "valid std handles can substitute for a console", and matches the README's "pipe-based stdio redirection is unaffected".
Evidence: the two mechanisms are independent
Built the restricted token directly (
CreateRestrictedTokenwithWRITE_RESTRICTED) and spawned withCreateProcessAsUserW, crossing parent-console state with the restricting list:0x00xC00001420xC0000142AllocConsole()in the runner0x0AllocConsole()0xC0000142(decisive)0xC0000142M4shows the console fix works;M5shows it does not rescue a token whose restricting list lacks the keep-alive group.Rejected alternatives (all measured)
CREATE_NEW_CONSOLE(0x10) on the child0xC0000142CREATE_NO_WINDOWon the childProposed fix
Layer 1 (required): give the runner a console when it has none, before spawning, and hide it so GUI users never see a console flash.
Placement: in
main(), immediately after theSetConsoleCtrlHandlercheck and beforenew AclSandbox(...). Failure must be fail-open (one warning line, keep going): a setup without a console then behaves exactly as it does today.Layer 2 (required, regression guard): assert before
CreateRestrictedTokenthat the restricting list contains both keep-alive members, and fail with a message naming the missing side instead of letting the user see a bare0xC0000142.Layer 3 (cheap, high value): when the mirrored child exit code equals
3221225794, write one stderr line stating console presence and pointing at the README section — so the next report carries a real code plus a hint instead of empty output.Verified locally: with this shim in front of the shipped
runner.jsandDeepSeek Harness.exeas the parent, the confinedpowershell.exeruns and returns0x0(row A5).Patch (git diff, +56 lines, applies to master@f3803c9)
If a visible console window is unacceptable, an alternative is a dedicated hidden console host plus
AttachConsole;AllocConsole+ShowWindow(SW_HIDE)is the shortest path and is what this report verified.Limits
0xC0000142" is measured, not explained at the loader level: no debugger was attached to the dying child.README:189"tree carrying another sandbox's package SID" shape. A directCreateProcessAsUserWcall from inside the confined shell would settle it.System32; that is a different layer and both could be real.All reactions