[Bug] Windows: windows-acl rung is auto-selected without a probe, but its host-side write grant always fails without SeSecurityPrivilege

[xiaojiu190918]

[Bug] Windows: windows-acl 沙箱档位免探测即被选中，但其宿主侧 write grant 必然失败 → workspace-write 下每条命令都报 Win32 5

该文档同时是本地留档与上游 Discussion 正文，已脱敏（工作区路径、用户名、计算机名均以占位符替代）。
提交位置：https://github.com/deepseek-ai/deepseek-harness/discussions （General）
依据 CONTRIBUTING.md：「Identify and report issues or bugs in GitHub Discussions」

版本：@deepseek-ai/dsh 0.1.7-alpha.1 ｜ 平台：Windows 11 + PowerShell 7.6.6 ｜ 宿主权限：非提权标准用户（Medium 完整性）

---

Summary

On Windows, the ACL sandbox rung (windows-acl) is selected without a probe (it is the only candidate in PLATFORM_CHAINS.win32), yet its host-side write grant unconditionally writes a Low mandatory integrity label into the object's SACL. Writing a SACL requires SeSecurityPrivilege, which a non-elevated host token does not have. The result:

• every single command in workspace-write mode fails with SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>);
• the availability probe nevertheless reports the rung as usable, because it only exercises the runner child (which runs with manageDacls: false and never writes a SACL);
• sessions therefore start in a mode in which no shell command can run at all, and users are pushed to danger-full-access to get any work done.

---

Environment

Item	Value
@deepseek-ai/dsh	0.1.7-alpha.1
OS	Windows 11 (build via win32), PowerShell 7.6.6
Host token	standard user, Medium integrity (S-1-16-8192), not elevated
Workspace	a normal directory on a fixed drive, fully writable by the user, no junctions

whoami /priv on the host process shows only:

SeShutdownPrivilege            Disabled
SeChangeNotifyPrivilege        Enabled
SeUndockPrivilege              Disabled
SeIncreaseWorkingSetPrivilege  Disabled
SeTimeZonePrivilege            Disabled

→ no SeSecurityPrivilege.

---

Impact

Observed over 39 recorded sessions (≈850 shell tool calls):

• workspace-write mode: 0 successes out of 6 real attempts; every attempt returned
  Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>).
• danger-full-access: 828 success / 23 ordinary non-zero exits.
• Net effect: the profile ends up running 99.2 % of all commands in danger-full-access,
  i.e. the file sandbox is effectively off — not because the user chose that, but because the
  only alternative silently fails. This weakens the confinement the feature is meant to provide.

A teammate/session started with approval: never has no recovery path at all: it cannot
escalate, and every command fails.

---

Root cause

1. The rung is chosen without any probe. dsh-sandbox-local/lib/index.js:

   const PLATFORM_CHAINS = { linux: [...], darwin: [...], win32: ["windows-acl"] };

   Per the accompanying comment, a chain is probed "only when it has MORE than one candidate".
   With a single candidate, windows-acl is accepted unconditionally.

2. The probe, if it did run, would not see the failure. defaultProbeWindowsAcl spawns the
   runner with --mode read-only:

   spawnSync(program, [...runnerInvocation.slice(1),
     "--workspace", tmpdir(), "--temp", tmpdir(), "--mode", "read-only",
     "--", "cmd", "/c", "exit", "0"], ...).status === 0

   while dsh-sandbox-windows-acl/lib/runner.js sets manageDacls: !seamManaged — i.e. the
   runner deliberately does not manage DACLs/SACLs. The part that does is the host-side
   AclWriteGrant, and that is never probed.

3. The host-side grant always writes a SACL. grantWrite in
   dsh-sandbox-windows-acl/lib/types-*.js:

   function grantWrite(api, path, sidPtr, lowLabelSidPtr, worldSidPtr) {
     withPathLock(api, path, () => {
       const { oldAcl, labelAcl, descriptor } = readCurrentSecurity(api, path);
       if (oldAcl !== null && labelAcl !== null && hasExactGrant(oldAcl, sidPtr)
           && hasExactDeny(oldAcl, worldSidPtr) && hasExactLabel(labelAcl, lowLabelSidPtr)) {
         return;                                   // all-or-nothing short circuit
       }
       const label = buildLowLabelAcl(api, lowLabelSidPtr);
       mergeAndApply(api, path, Buffer.concat([...]), oldAcl,
                     { kind: "apply", acl: label }, descriptor, "grantWrite");
     });
   }

   and mergeAndApply applies it with SecurityInfo = 20 (DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION):

   api.setNamedSecurityInfoW(path, 1, labelEdit.kind === "keep" ? 4 : 20,
                             null, null, newAcl,
                             labelEdit.kind === "apply" ? labelEdit.acl : null);

   When not short-circuited it is always kind: "apply", i.e. the label edit rides in the
   same call as the DACL edit → writing the SACL is unavoidable.

4. No privilege is ever enabled. A repository-wide search of
   dsh-sandbox-windows-acl for AdjustTokenPrivileges / LookupPrivilegeValue /
   SeSecurityPrivilege returns zero hits. The package assumes the token can write SACLs.

5. The short circuit cannot be leveraged as a workaround. It requires the capability ACE,
   the deny ACE and the label to match simultaneously:

   • workspaceWriteSid(workspaceRoot) is deterministic, so a one-time pre-grant could match —
     but
   • tempWriteSid(mkdtempSync(join(tmpdir(), "dsh-"))) is a fresh random directory per
     session, so the temp grant never matches and always takes the apply path.

   Pre-placing an inheritable Low label on %TEMP% does not help either, because the
   short circuit is all-or-nothing.

---

Evidence / reproduction

1. Token lacks the privilege — whoami /priv (above); Get-Acl -Path <dir> -Audit on any
   directory returns:

   The process does not possess the 'SeSecurityPrivilege' privilege which is required for this operation.
   

2. Independent reproduction without DSH — set the same integrity label on a scratch directory:

   icacls <scratch-dir> /setintegritylevel "(OI)(CI)Low"
   # Successfully processed 0 files; Failed processing 1 files
   # <scratch-dir>: Access is denied.
   # exit=5

   Exit code 5 = ERROR_ACCESS_DENIED, exactly the Win32 code DSH reports.

3. Reproduced through DSH — with the session in workspace-write, the very first command:

   {"tool":"pwsh","command":"Get-ChildItem \"D:\\...\\node_modules\\@deepseek-ai\" -Name"}

   returns:

   Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)
   

   The DACL-only path is not the blocker: the workspace directory is owned by the calling
   user and grants them full control, so WRITE_DAC is available. Only the SACL edit fails.

Why we believe this is not machine-specific

The failing operation is guarded by a token privilege, not by any directory ACL, so it should
reproduce on any Windows host whose dsh process is not running with SeSecurityPrivilege
(i.e. any ordinary non-elevated user, which is the normal way to run the web/desktop app).

---

Proposed fixes (any one would resolve the reported failure)

1. Enable what is available. At AclSandbox init, when the token holds SeSecurityPrivilege
   (admin tokens have it, disabled by default), enable it via
   LookupPrivilegeValue + AdjustTokenPrivileges for the grant duration.
2. Degrade explicitly instead of dying per command. If the privilege is absent, either
   • fall back to DACL-only confinement and report the rung as partial with a surfaced
     warning, or
   • fail the mode selection at session start with an actionable message
     (so a session never begins in a mode where every command is guaranteed to fail).
3. Make the probe honest. Have defaultProbeWindowsAcl exercise the host-side grant
   (create a throwaway directory, call AclWriteGrant.add, revoke, remove) rather than only
   starting the runner. This would make the rung unusable on affected hosts and let the
   platform chain report that properly.

---

Workaround we applied locally

In the profile patch layer:

- id: permission
  name: "@deepseek-ai/dsh-permission-presets"
  config:
    presets:
      workspace-write:    { sandbox: workspace-write,    approval: ask, ... }
      danger-full-access: { sandbox: danger-full-access, approval: never, ... }
      full-access-ask:    { sandbox: danger-full-access, approval: ask, ... }   # added
    defaultPreset: full-access-ask

i.e. default new sessions to full access while keeping the approval gate, purely so that
sessions stop starting in an unusable mode. This is a mitigation, not a fix: it means the file
sandbox is knowingly off.

---

Reported after a 39-session / ~65 MB execution-trace review of Windows shell failures.
Full local evidence: docs/kb-exec复盘与Windows原生化评估.md §8.

[argszero]

Thanks — this is the second report of this exact signature in two days, and its two halves land very differently. One half is already-diagnosed territory where the evidence shape does not decide the question; the other is new, correct, and wider than you state. Taking them in that order.

The SeSecurityPrivilege attribution is not established by this evidence

Two days ago #7538 (MichaelShii, also 0.1.7-alpha.1, Windows) reported the identical failure line:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(<workspace>)

That report is still open on one point, and yours repeats its structure: the repository documents the label's prerequisite as WRITE_OWNER — an object right on the directory — not as the SeSecurityPrivilege token privilege. Three places say so:

• packages/sandbox/sandbox-windows-acl/README.md:122 (and README.zh.md:122): "Granted directories must be caller-owned and grant WRITE_OWNER — the owner's implicit rights cover only READ_CONTROL and WRITE_DAC; the label lives in the SACL, so the combined apply additionally needs WRITE_OWNER (a Full-control directory, the normal workspace case, has it)."
• the grantWrite docstring, src/acl.ts:368-370 — the same sentence;
• the feature note .agents/notes/implemented/feature/2026-09-19-windows-acl-mandatory-integrity-confinement.md:47, which records it as a deliberate cost of the integrity layer.

The mechanism is the merge point you identify: acl.ts:255-259 passes DACL_SECURITY_INFORMATION | LABEL_SECURITY_INFORMATION in a single SetNamedSecurityInfoW call (labelEdit.kind === 'keep' is the only narrowing branch). The Low label lives in the SACL, so the label half is a SACL write — and the repo holds that an object-rights path satisfies it without the privilege.

Why whoami /priv cannot settle this. It enumerates token privileges. WRITE_OWNER is an object right on the directory and never appears there, so its absence is not evidence for the privilege hypothesis. Nor are the two mutually exclusive in the way the report needs: a directory whose access comes from an inherited Authenticated Users: Modify ACE — (A;ID;0x1301bf;;;AU), the shape #7538 read out of its own SDDL — carries no WRITE_OWNER and no ACE naming the caller's SID, so both hypotheses predict the denial. "A normal directory on a fixed drive, fully writable by the user" is exactly the phrase that leaves it open: mkdir D:\proj inherits from the drive root, and "writable" is the Modify mask.

Two discriminators, cheapest first:

1. Read-only. icacls <workspace> — is there an F (Full control) ACE naming your own SID? Full control carries WRITE_OWNER; Modify does not.
2. Mutating, one line, unelevated. icacls <workspace> /grant "$env:USERNAME:(OI)(CI)F" succeeds without elevation because the owner has WRITE_DAC; then retry the failing operation. Succeeds ⇒ WRITE_OWNER is the gate and README:122 holds. Still denied ⇒ the privilege really is required and that documented line (plus the feature note) is wrong — itself a report worth filing, because the design leans on it.

This is now the second report of the same signature, so the answer stops being academic: if both directories turn out to be Full-control, the documented object-rights claim is wrong; if both are Modify-only, the README prerequisite is not reaching users before they lose a working session.

The probe half is right — and wider than you state

I checked this against master (00102833df, 0.1.7-alpha.2). Your reading of PLATFORM_CHAINS and its comment matches packages/sandbox/sandbox-local/src/index.ts:160-168 verbatim. The gap is broader than "the probe exercises the wrong side":

1. On the product path the probe is never reached at all. chainVerdict (:503-514) destructures the chain and returns { runner: first, enforcement: STATIC_ENFORCEMENT[first] } for a sole candidate before probeRunner (:522). The rule is stated as deliberate policy at :152-158: "probing arbitrates; it does not re-validate a choice that has no alternative". internals.probeWindowsAcl is documented as the sole rung's probe, "only consulted if that chain ever grows" (:135) — unreachable on the shipped path.
2. Even if it were reached, it could not catch this. defaultProbeWindowsAcl (:101-115) spawns the runner with --mode read-only and --workspace tmpdir(). Read-only is exactly the branch of windowsAclRunnerArgv (:363-368) that passes no SID flags and materializes no grant at all; and the directory it names is the ambient temp, not the workspace. It asserts one thing: the runner can build a restricted token and spawn a child under it.

So it is a runner-availability probe, not a provisioning-capability probe. Lengthening PLATFORM_CHAINS.win32 to two entries — the repair the design invites — would still not catch your case; it would only start arbitrating between runners.

Where the failure actually costs, and where a fix belongs

The failing step is the host-side grant: AclWriteGrant.add → grantWrite (sandbox-windows-acl/src/grant.ts:107), reached from windowsAclRunnerArgv (sandbox-local/src/index.ts:373) → materializeAclGrant (:397). Two properties explain your numbers:

• it is materialized lazily, on the first confined workspace-write call, and the standing workspace ACE is the cross-session reuse cache — so a successful grant costs one propagation per provider lifetime, not per command;
• on throw nothing is cached (:401-417), so the next command attempts it again. That is why your observation is "every command fails" rather than "the first command fails", and why the loop cannot distinguish it from ordinary command noise — the same dynamic under which [BUG REPORT] Windows 沙箱无法在用户自建目录上 provision 工作区 ACE → 该目录下所有 shell 命令失败 #7538 spent ~52.6k output tokens over 11 calls before the environment was suspected at all.

The fix shape that matches the existing design is therefore a host-side preflight at the seam — attempt the standing grant once, before a session's first confined call — plus a first-class diagnostic naming the object-rights repair, instead of N identical failures. A probe cannot carry that, and neither can enforcement: the failure mode you measured (99.2% of commands in danger-full-access) is the confinement being abandoned, and an approval: never session has no way back at all. That last point is the strongest part of your report and worth keeping in the title.

Two notes on the design's own terms, both of which make the case wider than it may look:

• STATIC_ENFORCEMENT['windows-acl'] = 'partial' (:184-190) is a statement about enforcement completeness — hard links aliasing a granted file outside the tree, unconfined reads, AppContainer-ACL'd trees unreadable. It is not a concession about availability, so it does not cover unprobed selection; the two are separate claims, and yours is the second.
• The win32 chain comment says the sole candidate's refusal "fails closed through its stderr signature (windows-acl-run: ) and exit 127" (:163-166). Your failure happens before the runner is spawned, so that documented fail-closed path never fires: the process fails, but not through the mechanism the design names.

If an interim, plugin-form mitigation is wanted

SandboxProvider is a Cordis service with one abstract method, confine(argv, policy, signal) (packages/sandbox/sandbox/src/index.ts:158,176), and ctx.sandbox is what every executor calls (packages/shell/pwsh-sandbox/src/index.ts:195). So the service method is shadowable from a plugin: a wrapper could preflight the workspace's standing grant once and emit a single durable notice naming the fix, rather than letting each command fail. I have not built that — I am naming it only because it is the seam an interim mitigation would have to use, and because a plugin cannot swap the chain (internals.chain is a test hook; Config exposes only runnerCommand, runnerFailureSignatures, probeTimeoutMs).

[xiaojiu190918]

Follow-up from the reporter: we ran the two discriminators you named. You were right, and our SeSecurityPrivilege attribution was wrong.

Environment: Windows 11, @deepseek-ai/dsh 0.1.7-alpha.1, non-elevated standard user. The discrimination was run on a scratch subdirectory (the workspace root's ACL was not mutated while discriminating).

1. Read-only — icacls <dir>

A freshly created subdirectory inherits the same shape as our workspace:

<dir> xiaojiu\CodexSandboxUsers:(I)(OI)(CI)(M)
      S-1-5-21-...-2125252537:(I)(OI)(CI)(M)
      BUILTIN\Administrators:(I)(F)          NT AUTHORITY\SYSTEM:(I)(F)
      NT AUTHORITY\Authenticated Users:(I)(M) BUILTIN\Users:(I)(RX)

Owner: XIAOJIU\39696. Our own SID appears only through the inherited CodexSandboxUsers / Authenticated Users Modify entries — no F ACE naming our SID, i.e. no WRITE_OWNER. Exactly the shape you predicted from #7538's SDDL.

2. Mutating, unelevated

before:  icacls <dir> /setintegritylevel (OI)(CI)Low   ->  exit 5, "Access is denied."   (reproduces the reported failure)
         icacls <dir> /grant "39696:(OI)(CI)F"         ->  exit 0                        (unelevated, as you said: owner holds WRITE_DAC)
after:   icacls <dir> /setintegritylevel (OI)(CI)Low   ->  exit 0, success

So WRITE_OWNER is the gate, sandbox-windows-acl/README.md:122 (with the grantWrite docstring and the feature note) is correct, and our whoami /priv evidence could not have discriminated the two hypotheses — it enumerates token privileges, and WRITE_OWNER is an object right that never appears there. Accepted.

We then applied the same one-line grant to the actual workspace root and re-ran the label write on the root itself: exit 0 (previously exit 5). The confinement rung is now usable for us.

Which branch this lands in

Your second branch. The operative bug is the one you named:

users reach the failing path with a Modify-only workspace, and nothing preflights the standing grant or names the object-rights repair before the session's confinement is lost.

The cost was concrete on our side: every confined workspace-write call failed, so the workspace was unusable for confined work; because that session ran with approval: never there was no way back, and we ended up executing 99.2% of commands under danger-full-access — a silent widening of access caused by a failure the design reports only as a per-command error. One first-class diagnostic naming the unelevated repair (icacls <workspace> /grant "<user>:(OI)(CI)F") would have prevented all of it.

On the probe half

We also accept your wider reading and the correction: on the product path the probe is not reached at all (chainVerdict returns for the sole candidate before probeRunner), and even if it were reached it is a runner-availability probe (--mode read-only, tmpdir(), no SID flags, no grant materialized), not a provisioning-capability probe — so lengthening PLATFORM_CHAINS.win32 would not have covered this case either. That part of the report stands only as "the sole candidate is selected without arbitration", which is policy, not defect.

Offer

If useful, we can build the interim mitigation at the seam you pointed at — a wrapper shadowing SandboxProvider.confine via ctx.sandbox that preflights the standing grant once per session and emits a single durable notice instead of N identical per-command failures. Happy to do it if you want a plugin-form stopgap; otherwise consider our report superseded by the host-side preflight + first-class diagnostic you proposed.