[Bug] Windows：工作区位于非系统盘时 ACL 沙箱必然初始化失败（Win32 5 / grantWrite）/ ACL sandbox fails on non-system drives: the default ACL grants the caller no WRITE_OWNER

[CNyaotian-Lunar]

环境 / Environment

• Windows 11，全部卷均为 NTFS（Get-Volume 确认，不是 FAT 卷）

• DSH 0.1.7-rc.2（npm next 通道）；沙箱后端 @deepseek-ai/dsh-sandbox-windows-acl（随 0.1.7-rc.2 提供）

• 文件策略：workspace-write

• 工作区：非系统盘上的目录（F:\<workspace>，不在 %USERPROFILE% 之下）

• 进程身份：普通用户（未提权），whoami /groups 显示 Mandatory Label\Medium Mandatory Level

• Windows 11, all volumes NTFS (Get-Volume confirms; it is not a FAT volume)

• DSH 0.1.7-rc.2 (npm next channel); sandbox backend @deepseek-ai/dsh-sandbox-windows-acl (shipped with 0.1.7-rc.2)

• File policy: workspace-write

• Workspace: a directory on a non-system drive (F:\<workspace>, not under %USERPROFILE%)

• Process identity: regular user (unelevated); whoami /groups shows Mandatory Label\Medium Mandatory Level

现象 / Symptom

将文件策略设为 workspace-write 后，所有 pwsh / bash 调用立即失败 —— 连无副作用的最小命令都不行：

With the file policy set to workspace-write, every pwsh / bash invocation fails immediately — even a side-effect-free minimal command:

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

同一会话内把策略切回 danger-full-access，同一条命令立刻正常。⇒ 失败发生在沙箱初始化阶段（子进程尚未创建），不是命令本身的问题。

Switching the policy back to danger-full-access in the same session makes the very same command work immediately. ⇒ The failure happens during sandbox initialization (no child process is ever created), so it is not about the command itself.

按包内 README 的说明，init() 是 fail-closed：任何 Win32 失败都会抛错、绝不 spawn 未受限的子进程 —— 这个行为本身是对的；问题在于该环境下永远无法满足 grantWrite 的前提，而且用户拿不到可操作的提示。

As the package README states, init() is fail-closed: any Win32 failure throws and an unrestricted child is never spawned — that behavior is correct; the problem is that in this environment the precondition of grantWrite can never be satisfied, and the user gets no actionable hint.

根因 / Root cause

grantWrite() 在一次 SetNamedSecurityInfoW 调用里同时改 DACL 与 SACL 的 mandatory integrity label（LABEL_SECURITY_INFORMATION）。

grantWrite() changes the DACL and the SACL's mandatory integrity label (LABEL_SECURITY_INFORMATION) in a single SetNamedSecurityInfoW call.

• 目录的属主只隐含 READ_CONTROL + WRITE_DAC；写标签需要 WRITE_OWNER（与包内 README「被授权目录必须由调用者拥有并授予 WRITE_OWNER」的已知限制一致）。
  A directory's owner implies only READ_CONTROL + WRITE_DAC; writing the label needs WRITE_OWNER (consistent with the package README's known limitation: the granted directory must be owned by the caller with WRITE_OWNER granted).
• Windows 非系统盘的默认 ACL 为 NT AUTHORITY\Authenticated Users: Modify + BUILTIN\Users: ReadAndExecute（继承），不含创建者/调用者的 FullControl ⇒ 调用者没有 WRITE_OWNER。
  A non-system drive's default ACL is NT AUTHORITY\Authenticated Users: Modify + BUILTIN\Users: ReadAndExecute (inherited) and does not include FullControl for the creator/caller ⇒ the caller lacks WRITE_OWNER.
• 于是 SetNamedSecurityInfoW 返回 ERROR_ACCESS_DENIED (5)，init() fail-closed 抛错。
  Hence SetNamedSecurityInfoW returns ERROR_ACCESS_DENIED (5) and init() throws, fail-closed.

对照事实：C:\Users\<user>\… 下新建的目录天生带调用者 FullControl（继承），因此同样代码在系统盘用户目录下工作正常 —— 这也是为什么该问题在常规开发环境下不会被发现。

For contrast: directories created under C:\Users\<user>\… inherit FullControl for the caller, so the same code works fine there — which is exactly why this problem is invisible in the usual development setup.

复现后现场 ACL 里可以看到沙箱此前成功授予过留下的能力 SID ACE（S-1-4-…），说明该目录曾经满足过前提；一旦换成"非系统盘新建目录"这种默认 ACL，就会稳定失败。
After reproducing, the live ACL shows a leftover capability-SID ACE (S-1-4-…) from a previous successful grant, i.e. the directory once satisfied the precondition; with the default ACL of a "fresh directory on a non-system drive" it fails deterministically.

最小复现 / Minimal reproduction

不需要启动 DSH，用系统自带 icacls 就能复现同一条权限路径：

No DSH install needed — the built-in icacls reproduces the very same privilege path:

# 1) 非系统盘新建目录（继承该盘默认 ACL）/ create a directory on a non-system drive (inherits that volume's default ACL)
New-Item -ItemType Directory -Force F:\probe | Out-Null
(Get-Acl F:\probe).Access | Where-Object IdentityReference -match $env:USERNAME   # → 无输出：调用者没有显式 ACE / no output: caller has no explicit ACE

# 2) 写 Low 完整性标签 == 沙箱 grantWrite 要做的同一件事 / write the Low integrity label == what sandbox grantWrite does
icacls F:\probe /setintegritylevel Low
#   → Access is denied. (exit code 5)          ← 与 DSH 报的 Win32 5 一致 / same Win32 5 DSH reports

# 3) 给调用者补一条完全控制（含 WRITE_OWNER）/ grant the caller FullControl (includes WRITE_OWNER)
icacls F:\probe /grant "$env:USERNAME:(OI)(CI)F"

# 4) 同一操作立刻成功 / the same operation now succeeds
icacls F:\probe /setintegritylevel Low
#   → Successfully processed 1 files. (exit code 0)

对照实验：在 C:\Users\<user>\ 下重复第 1~2 步 —— 天生成功（新目录继承调用者 FullControl）。

Control experiment: repeat steps 1–2 under C:\Users\<user>\ — it succeeds out of the box (new directories inherit FullControl for the caller).

影响 / Impact

• 任何把工作区放在非系统盘的 Windows 用户：workspace-write 完全不可用（AI 无法执行任何 shell 命令），只能退到 danger-full-access —— 恰好是沙箱想要避免的那个状态。这属于静默降级成不安全配置的路径。
  Any Windows user whose workspace lives on a non-system drive: workspace-write is entirely unusable (the agent cannot run any shell command), forcing a fallback to danger-full-access — precisely the state the sandbox exists to prevent. This is a silent downgrade to an unsafe configuration.
• 报错只有裸 Win32 5，没有说明"该目录缺少 WRITE_OWNER"，也没有修复办法；README 里的限制说明在故障当下不可见（用户看到的只是 GUI 里一条报错）。
  The error is a bare Win32 5 with no mention that the directory lacks WRITE_OWNER and no fix; the README limitation is invisible at failure time (all the user sees is one error line in the GUI).
• 失败是必然且稳定的（不是竞态），因此会直接劝退这一类用户使用沙箱。
  The failure is deterministic and stable (not a race), which effectively drives this class of users away from the sandbox.

修复方法 / How to fix

A. 立刻可用（用户侧）/ Immediately available (user side)

给工作区目录补一条调用者的完全控制（含 WRITE_OWNER），沙箱即可正常初始化：

Grant the workspace directory FullControl for the caller (which includes WRITE_OWNER) and the sandbox initializes normally:

icacls <workspace> /grant "<user>:(OI)(CI)F"     # 全树继承传播约 3~4 分钟 / propagates across the tree, ~3–4 min
# 回滚 / rollback：
icacls <workspace> /remove:g "<user>"

（等价替代：icacls <workspace> /setowner "<user>"，或把工作区放到 C:\Users\<user>\… 之下。）

(Equivalents: icacls <workspace> /setowner "<user>", or simply put the workspace under C:\Users\<user>\….)

B. 根治（上游）/ Proper fix (upstream)

1. 启动时预检 + 可执行指引：在 init() 之前对每个 writable root 做能力探测（能否写 SACL / 是否具备 WRITE_OWNER）。失败时给出可直接粘贴的修复命令（即上面那条 icacls）与文档链接，而不是只抛 Win32 码。
   Pre-flight check + actionable guidance: probe each writable root's capability (can it write the SACL / does it have WRITE_OWNER) before init(), and on failure print the paste-ready fix command above plus a doc link, instead of a bare Win32 code.
2. 可选的降级而非全盘失败：若写 SACL 标签失败，是否可以在**明确告知"隔离强度下降"**的前提下，只施加 capability ACE 并继续（或在错误里区分「DACL 写入失败」与「标签写入失败」两个分支）？当前"整条命令路径全死"的代价，比"少了 Low 标签"更大。
   Optional degradation instead of total failure: when the SACL label write fails, could DSH still apply the capability ACE and continue, while clearly reporting reduced isolation strength? (Or at least distinguish "DACL write failed" from "label write failed" in the error.) Today's cost — the entire command path dying — is larger than the missing Low label.
3. 文档/UI 明确前提：工作区需位于调用者拥有完全控制的目录；非系统盘默认 ACL 不满足，并给出一次性授权步骤。
   Document the precondition (both README and UI): the workspace must live in a directory the caller fully controls; non-system drives do not satisfy this by default — include the one-time grant step.
4. 可选的显式初始化命令（例如 --grant-workspace-acl）：在用户知情下完成能力 SID 授权与 Low 标签施加，与当前 standing-grant 的设计一致（保持"常驻 ACE 作复用缓存"的既有语义）。
   Optional explicit initialization command (e.g. --grant-workspace-acl): perform the capability-SID grant and Low label on the user's explicit behalf, consistent with today's standing-grant design ("persistent ACE as a reuse cache").
5. read-only 建议纳入同一预检：它本身不 grant，但 spawn 的 Low 完整性令牌仍依赖标签可达性。
   read-only should share the same pre-flight: it grants nothing itself, but the spawned Low-integrity token still depends on the label being reachable.

相关 / Related

• [Bug/UX] Windows：工作区目录所有者为 BUILTIN\Administrators 时，workspace-write 下所有命令直接失败（grantWrite / SetNamedSecurityInfoW Win32 5） #7771 —— 同一缺陷的另一个入口（目录所有者是 BUILTIN\Administrators）/ the other entry point of the same defect (directory owner is BUILTIN\Administrators)

本报告由 DSH agent 定位整理、经人工复核。
Located and written up by a DSH agent, reviewed by a human before posting.

[argszero]

A correction to suggested fix 5, and where your (OI)(CI)F observation ended up

Thanks for the paste-ready icacls reproduction and the per-version comparison — both are cited in @argszero/cordis-plugin-sandbox-grant-advisor (npm / public repo), which recognizes this signature on the public tools/post-execute waterfall and attaches a user-role advisory to the failing result, since the error itself names no cause and no remedy. 0.5.0, published today, is the first release that handles this shape properly; that release is largely a response to your report.

Suggested fix 5 (share the pre-flight with read-only) — read-only cannot reach this failure

There is nothing to pre-flight on that path, because no security descriptor is ever written in read-only:

• sandbox-local skips the grant entirely for that mode — packages/sandbox/sandbox-local/src/index.ts:365: sessionId === undefined || policy.mode === 'read-only' returns the argv without materializeAclGrant; and the runner passes writableDirs: parsed.mode === 'workspace-write' ? [parsed.workspace] : [] with no write SID (sandbox-windows-acl/src/runner.ts:163).
• AclSandbox.init() calls grantWrite only for this.writableDirs and only when a write SID exists (sandbox-windows-acl/src/index.ts:268-271). With neither, no SetNamedSecurityInfoW runs at all: no DACL write, and no label write.

You are right that the token is still lowered in both modes — restrictTokenIntegrity runs unconditionally (src/index.ts:289) — but read-only grants no write capability anywhere, so the label is not what confines it. The label only ever accompanies a granted directory, which is exactly why this failure is specific to workspace-write.

Suggested fix 2 (degrade instead of failing) — the diagnostic half is the part worth keeping

I would not ship the degradation as a default, for the reason kittimzhe works out on #7816: the sandboxed token is Low integrity and a Low process cannot write a Medium-labelled directory (no-write-up), so skipping the label on ERROR_ACCESS_DENIED would let the grant report success while the sandbox's actual writes kept failing — the loud error replaced by a silently broken one. What is worth keeping from your suggestion is the diagnostic half, and it is compatible with staying fail-closed: distinguishing "DACL write failed" from "label write failed". That is upstream's to add in src/acl.ts; a plugin can only explain a failure that has already happened.

Where your (OI)(CI)F observation ended up

Your report is the reason the advisory now forks. (WO) alone is right only where the caller owns the directory; where they do not — #7771, owner BUILTIN\Administrators, held deny-only for that token — icacls /grant is itself refused for want of WRITE_DAC, and (WO) would not be enough even if it went through, since the merged write wants WRITE_DAC and WRITE_OWNER. So 0.5.0 hands over the ownership check as the branch selector, (Get-Acl "<dir>").Owner, and gives each branch its own command:

• caller owns it — the unelevated icacls "<dir>" /grant "<user>:(OI)(CI)(WO)" ([Windows] workspace-write 沙箱在数据盘工作区完全不可用：SetNamedSecurityInfoW failed (Win32 5) #7750 verified that form working), or the same line with F;
• caller does not — an elevated icacls "<dir>" /grant "<your-account>:(OI)(CI)F", which is the form your report measured, or /setowner first (also elevated), after which the unelevated line applies, or a workspace under %USERPROFILE%.

Your non-system-drive half is named in the advisory too, alongside the inherited-Modify shape — the same text covers both, since the error cannot separate them.

Scope

A stopgap, not a fix: the plugin never edits an ACL and never elevates, and the upstream gap is still open in packages/sandbox/sandbox-windows-acl/src/acl.ts — verified at master 477b4f4205, where mergeAndApply still applies DACL and label in one call and the failure text is still the bare Win32 code.

• install: npm i @argszero/cordis-plugin-sandbox-grant-advisor

[CNyaotian-Lunar]

〇、先道谢，也先道歉

谢谢你逐条核实，并把我们的观测采纳进了 0.5.0 的分叉逻辑 —— 这直接让非系统盘的用户拿到了可粘贴的修复命令；也谢谢你引用这份报告、把它和 #7750 / #7816 串成了一条完整的证据链。同时要为我们那份报告道歉：两条建议里，一条的前提是错的，另一条的一半会造成静默损坏，正文里还有一处「等价替代」写错了。以下是逐条更正。

Thank you — and apologies. Thank you for checking this line by line and for folding our observation into 0.5.0's branching, which puts a paste-ready fix directly in front of non-system-drive users; and for citing this report and tying it together with #7750 / #7816 into one evidence chain. Apologies for our report: of its two suggestions, one rests on a false premise and half of the other would produce a silent break, and one "equivalent" line in it is simply wrong. Corrections follow.

一、先接受两处更正 —— 我们撤回建议 5，并收窄建议 2

我们独立复读了 0.1.7-rc.2 的编译产物，你说的两处都成立。

建议 5（read-only 共享同一预检）—— 撤回。 证据：

• dsh-sandbox-windows-acl/lib/runner.js:144：writableDirs: parsed.mode === "workspace-write" ? [parsed.workspace] : []
• .../lib/types-DxezulnA.js:1189-1200：grantWrite() 仅在 this.writeSidPtr !== void 0 时被调用；而构造函数层面就禁止 read-only 携带 write SID（同文件 :1151）

⇒ read-only 从不写任何安全描述符，不可能走到这条失败路径。你（以及 #7816 的 kittimzhe）的判断成立，我们那条前提是错的。

建议 2 的「跳过标签降级」—— 撤回；只保留诊断那一半。 我们核实 restrictTokenIntegrity() 在 init() 中是无条件执行的（:1204，不在任何 mode 分支内），而 read-only 的 restricting 列表里不含 write SID（:880）。⇒ 令牌是 Low、目录停留在 Medium（未打标签）时，沙箱内的写入会被 no-write-up 拒绝：授权会「成功」而沙箱实际写不进去 —— 正是「用静默损坏换一个响亮的错误」。我们同意不作默认降级，并继续支持**区分「DACL 写入失败」与「标签写入失败」**这一诊断性改动。

二、我们报告里的一处错误，由我们自己更正

正文 A 节把 icacls <workspace> /setowner "<user>" 列为等价替代 —— 不成立：当所有者已经是调用者本人时它是 no-op（既不改 DACL、也不授予任何新权限）；当所有者不是调用者时，它本身还需要提权，且所有者身份只隐含 READ_CONTROL + WRITE_DAC（不含 WRITE_OWNER），之后仍须补 (WO)。

三、一处场景归属需要澄清（对你的 advisory 有直接影响）

本报告的场景是非系统盘 + 目录所有者就是调用者本人，不是 #7771 的 BUILTIN\Administrators。你在 #7804 的回复里把本报告归入了 "caller does not own it" 分支 —— 并因此给出 elevated icacls "<dir>" /grant "<account>:(OI)(CI)F"。按这个归属，非系统盘用户会看到一个并不需要的提权步骤。

我们刚在受影响的机器上做了最小复现（Windows 11 / NTFS / 非系统盘 F: / 全新目录 / 普通未提权进程）：

F:\_acl-probe-20260925        owner = YAOTIAN-PC\17125（就是调用者本人）
STEP 1  icacls <dir> /setintegritylevel Low                      → Access is denied. (exit 5)      ← 复现
STEP 2  icacls <dir> /grant "YAOTIAN-PC\17125:(OI)(CI)(WO)"      → Successfully processed (exit 0)
STEP 3  icacls <dir> /setintegritylevel Low                      → Successfully processed (exit 0)  ← 修复

⇒ 在「非系统盘 + 自己拥有」这一格里，最小充分权限就是 (WO)（F 同样可行，但不是最小），而且两者都不需要提权。你的分叉判据 (Get-Acl "<dir>").Owner 本身是对的，只是这份报告属于「caller owns it」那一侧。

四、一条补充观察：沙箱内的 agent 无法自救

我们在 workspace-write（受限令牌内）跑同一批 icacls 时全部 Access is denied：沙箱令牌对该目录的写权限只有 capability SID 的 (W,D,DC)，不含 WRITE_DAC。⇒ 沙箱内运行的 agent 自己修不了这个 ACL。这反过来支持「预检 + 用户侧一次性修复」是唯一可行路径，也说明任何「运行时自动修复」的设想都不成立。

---

English version

1. Two corrections accepted — we withdraw suggestion 5 and narrow suggestion 2

We re-read the compiled 0.1.7-rc.2 artifacts; both of your points hold.

Suggestion 5 (read-only sharing the pre-flight) — withdrawn. Evidence:

• dsh-sandbox-windows-acl/lib/runner.js:144: writableDirs: parsed.mode === "workspace-write" ? [parsed.workspace] : []
• .../lib/types-DxezulnA.js:1189-1200: grantWrite() is invoked only when this.writeSidPtr !== void 0, and the constructor forbids read-only from carrying a write SID at all (:1151).

⇒ read-only never writes a security descriptor, so it cannot reach this failure path. You (and kittimzhe on #7816) are right; our premise there was wrong.

The "skip the label" half of suggestion 2 — withdrawn; only the diagnostic half stays. restrictTokenIntegrity() runs unconditionally inside init() (:1204, outside any mode branch), while read-only's restricting list carries no write SID (:880). ⇒ With a Low token and a Medium (unlabelled) directory, writes inside the sandbox are refused by no-write-up: the grant would report success while nothing could actually be written — a loud error traded for a silent one. We agree it must not be a default, and we still support distinguishing "DACL write failed" from "label write failed".

2. A correction to our own report

Section A listed icacls <workspace> /setowner "<user>" as an equivalent — it is not. Where the owner already is the caller it is a no-op (it changes neither the DACL nor any right); where it is not, the operation itself needs elevation, and ownership implies only READ_CONTROL + WRITE_DAC (not WRITE_OWNER), so a (WO) grant is still required afterwards.

3. One attribution that directly affects your advisory

This report's environment is non-system drive + the caller is the directory owner — not #7771's BUILTIN\Administrators. In your #7804 reply this report is filed under the "caller does not own it" branch, which yields an elevated icacls "<dir>" /grant "<account>:(OI)(CI)F". On that reading, non-system-drive users would be shown an unnecessary elevation step.

We just ran the minimal reproduction on an affected machine (Windows 11 / NTFS / non-system drive F: / fresh directory / ordinary unelevated process):

F:\_acl-probe-20260925        owner = YAOTIAN-PC\17125  (the caller itself)
STEP 1  icacls <dir> /setintegritylevel Low                      → Access is denied. (exit 5)      ← reproduced
STEP 2  icacls <dir> /grant "YAOTIAN-PC\17125:(OI)(CI)(WO)"      → Successfully processed (exit 0)
STEP 3  icacls <dir> /setintegritylevel Low                      → Successfully processed (exit 0)  ← fixed

⇒ For "non-system drive + caller-owned", the minimal sufficient right is (WO) (F also works, but is not minimal), and neither needs elevation. Your branch selector (Get-Acl "<dir>").Owner is right; this report simply belongs on the "caller owns it" side.

4. One extra observation: an agent inside the sandbox cannot repair this itself

Running the same icacls calls under workspace-write (inside the restricted token) gives Access is denied for all of them: the sandbox token holds only the capability SID's (W,D,DC) on that directory, with no WRITE_DAC. ⇒ An agent running under the sandbox cannot fix this ACL on its own. That further supports "pre-flight + a one-time user-side fix" as the only workable path, and rules out any "self-healing at runtime" design.