Windows ACL 沙箱在 UNC/9P 工作区根（\\wsl.localhost\…）上 GetNamedSecurityInfoW 返回 ERROR_INVALID_FUNCTION，导致 workspace-write 下 PTC worker 启动即失败

[USTHzhanglu]

环境

• DSH Desktop 0.2.0-rc.2（channel nightly，win-x64）；同症状在 npm 线 @deepseek-ai/dsh 0.2.0-rc.2（web/CLI）上同样成立 —— 二者的 @deepseek-ai/dsh-base 都挂 - id: ptc-runtime → @deepseek-ai/dsh-ptc-runtime-node 与 - id: sandbox → @deepseek-ai/dsh-sandbox-local
• @deepseek-ai/dsh-sandbox-windows-acl / dsh-sandbox-local / dsh-ptc-runtime-node（随 0.2.0-rc.2 打包；0.2.1-alpha.2 的 lib/types-Cl_DXjhk.js 与 rc.2 md5 相同，未修）
• Windows 11 10.0.26300.0，PowerShell 5.1.26100.9549
• WSL 3.0.1.0，内核 6.18.40.1-microsoft-standard-WSL2，Ubuntu 26.04 LTS
• 会话工作区根为 UNC：\\wsl.localhost\...，策略 workspace-write

现象 / 日志

Error: code run failed (worker-exit): GetNamedSecurityInfoW failed (Win32 1): \\wsl.localhost\...
File sandbox: workspace-write.

• 程序体只有 return 1; 也失败 → 失败在 worker 启动阶段，与程序内容无关。
• 同一调用 danger-full-access 正常（ptc-runtime 对 danger-full-access 跳过 confine()）。
• 期望的失败名是 sandbox-unavailable（runtime 里有这个分类），实际报成 worker-exit，且消息里没有“这个根不支持 ACL 沙箱”的任何提示。

最小复现（DSH 内）

1. 会话工作区根设为 \\wsl.localhost\<distro>\<linux 路径>（dsh-wsl-workspace 插件就是这么注册的；web 侧用 npx --yes @deepseek-ai/dsh@next web 同样能复现），策略 workspace-write。
2. run_code 任意程序（含无工具调用的 return 1;）→ 必现上面报错。
3. 对照：同程序加 danger-full-access → 成功；工作区换成 Windows 盘路径（如 D:\project\…）+ workspace-write → 成功。

对照结论：同一台机器、同一 API，本地 NTFS 根返回 0，9P（\\wsl.localhost\…）根返回 1。9P 重定向器不提供安全描述符，ACL 沙箱在这类根上原理上无法工作。

定位

• dsh-ptc-runtime-node/lib/index.js:950 → await this.ctx.sandbox.confine(argv, …)（provider 的 static inject 含 sandbox / sandboxPolicy，解析的是它所在 realm 的服务；该行挂在宿主平面，所以永远是宿主 sandbox）

• dsh-sandbox-local/lib/index.js:176 → win32: ["windows-acl"]（win32 只有这一个后端，没有 UNC/网络路径分支）

• dsh-sandbox-windows-acl/lib/types-Cl_DXjhk.js:400-407 → readCurrentSecurity()：

  const readResult = api.getNamedSecurityInfoW(path, 1, 20, ownerSlot, groupSlot, daclSlot, saclSlot, descriptorSlot);
  if (readResult !== 0) throwWin32(api, "GetNamedSecurityInfoW", readResult, path);

  调用点只有 grantWrite（:592）与 revokeWrite（:629）→ 只有 workspace-write 需要写授权时才会读 ACL；read-only 不申请写授权，理论上不触发（未实测）。

• 失败发生在 worker 约束准备阶段，dsh-ptc-runtime-node 的归类（lib/index.js:1164/1170）把它落成 worker-exit，而不是 sandbox-unavailable。

影响

• 任何以 UNC（WSL 9P、SMB、云盘虚拟盘）为工作区根的会话，在 workspace-write 下 run_code / PTC 模式完全不可用，只能每次提权到 danger-full-access（等于放弃围栏）；在 WSL 场景里，插件已把 bash/fs/搜索/终端都绕开了这条运行器，只有宿主 PTC 这一条还在踩。
• 报错对用户不可诊断：既没说“这个根不支持”，也没给出可行动的下一步。
• 附带的 diagnose-windows-sandbox-acl 技能在这里无效 —— 它修的是 ACL 权限，而 9P 根本不提供安全描述符。

官方讨论板检索结论与交叉引用（2026-10-10）

• #9195 Windows sandbox troubleshooting index: routing workspace-write failures beyond 0xC0000142 —— 索引帖按“失败发生在哪一步”分派。它收录的是 SetNamedSecurityInfoW failed (Win32 5): grantWrite(...)（ACL 授权失败）那一路，本条是读安全描述符就失败（GetNamedSecurityInfoW，Win32 1），索引里没有这一类 → 建议补一条新分支：“根无法承载安全描述符（UNC / 9P / 云盘虚拟盘）→ readCurrentSecurity() 抛 ERROR_INVALID_FUNCTION”。
• ACL provisioning 一族（同代码点，不同 Win32 码）：Windows: workspace-write sandbox fails with SetNamedSecurityInfoW Win32 5 when the workspace directory DACL lacks WRITE_OWNER #7504、[BUG REPORT] Windows 沙箱无法在用户自建目录上 provision 工作区 ACE → 该目录下所有 shell 命令失败 #7538、[Bug Report] Windows: workspace ACL with Modify-only (no WRITE_OWNER) makes the ACL sandbox fail at init, disabling all shell tools #7720、# [Windows] 非系统盘工作区在 sandbox provisioning 阶段 fail-closed（Win32 5），且唯一官方修复手段与「避免 Low 完整性标签副作用」不可兼得 #8275、[Bug/UX] Windows：工作区目录所有者为 BUILTIN\Administrators 时，workspace-write 下所有命令直接失败（grantWrite / SetNamedSecurityInfoW Win32 5） #7771、【Bug】[Windows] Workspace at user home dir breaks all shell commands ("Windows ACL temp root must be outside the workspace") and the agent then repeats one identical failing tool call 150 times with no circuit breaker #7583。
• Low integrity label 一族（同沙箱的副作用）：[0.2.0-rc.2][Windows] workspace-write: subdirectories unwritable — Low mandatory label not inherited by children (DACL grant present) #8383、[Windows] Low integrity label is written only on the workspace root, so every pre-existing subdirectory stays unwritable to confined processes under workspace-write #8421、[BUG](windows沙箱问题)(DSH GUI模式)会话里跑在非「完全权限」模式在项目文件夹根目录生成Windows 强制完整性标签，导致二进制生成文件权限受限 #9086。
• “特殊文件系统 / 网络路径 vs 沙箱”同类：[#3919](https://github.com/deepseek-ai/deepseek-harness/discussions/3919)（Google Drive 虚拟盘，SetFileSecurityW Win32 87）、[#3749](https://github.com/deepseek-ai/deepseek-harness/discussions/3749)（SMB 映射盘被判“超出工作区”）、[#9223](https://github.com/deepseek-ai/deepseek-harness/discussions/9223)（映射盘符拼写）。
• WSL 一族：**[#8644](https://github.com/deepseek-ai/deepseek-harness/discussions/8644)**（另一插件把沙箱搬进发行版，原话确认 “DSH's Windows ACL runner cannot reach WSL at all”）、[#8371](https://github.com/deepseek-ai/deepseek-harness/discussions/8371)（官方桌面端不支持 wsl）。

建议

1. dsh-sandbox-local / dsh-sandbox-windows-acl：对无法承载安全描述符的根显式识别（UNC 前缀 / PathIsNetworkPathW / GetDriveType = DRIVE_REMOTE，或把 GetNamedSecurityInfoW 的 ERROR_INVALID_FUNCTION、ERROR_NOT_SUPPORTED 视作“该根不支持”），返回 SandboxUnavailableError（→ sandbox-unavailable）并附一句可行动的说明，而不是把原始 Win32 错抛进 worker 启动路径。
2. 降级处理（更彻底、也更省事）：这类根上不施加写授权，如实报告 enforcement: 'partial' / 只读效果 —— 这样 run_code 立刻可用，插件侧（WSL 世界）也不必再想办法绕。
3. dsh-ptc-runtime-node：把 runner 准备阶段的抛错也按 sandbox-unavailable 归类（现在只有 isRunnerSpawnFailure 的窄判据），避免用户只看到 worker-exit。
4. 请求把本类挂进 [#9195](Windows sandbox troubleshooting index: routing `workspace-write` failures beyond `0xC0000142` #9195) 索引（“root cannot carry a security descriptor”分支）。

验证修复

• 权限对照：run_code 同程序 workspace-write vs danger-full-access（修复前：前者失败、后者成功；修复后应两者都成功，且 result.sandbox.enforcement 如实为 partial）。
• 平台对照：repro-acl.ps1（UNC 根 = 1 / NTFS 根 = 0）；修复后 UNC 根上的调用不应再抛原始 Win32 错。
• 交叉平台对照：Windows 盘工作区不受影响，说明改动只落在“无法承载安全描述符的根”这一分支上。

[PerryLink]

报错、参数、失败点我都核到了，你的现象描述是准确的。但有一处归因需要更正 —— 改对之后，修复点会从"放宽分类"变成"补一次包装"，落点完全不同。

1. 失败点与文案，逐字命中

• packages/sandbox/sandbox-windows-acl/src/acl.ts:150-154：

getNamedSecurityInfoW(path, SE_FILE_OBJECT, DACL | LABEL, …)
…
throwWin32(api, 'GetNamedSecurityInfoW', readResult, path)

• 常量对得上你反编译看到的 1, 20：win32-abi.ts:73 = 1（SE_FILE_OBJECT）、:44 = 0x4（DACL）、:46 = 0x10（LABEL），或起来就是 20
• 文案形状来自 packages/subprocess/win32-process/src/errors.ts:9 → `${api} failed (Win32 ${win32Code})${detail ? ': ' + detail : ''}`，:2 的 class Win32Error extends Error ⇒ 你看到的 GetNamedSecurityInfoW failed (Win32 1): \\wsl.localhost\… 完全吻合

9P/WSL 不提供 Windows 安全描述符，所以 ERROR_INVALID_FUNCTION (1) 是合理的返回值 —— 这一层你说得对。

2. ⚠️ 但归因要改：这次失败不走 runner 那条路

最新代码里有两条失败分类路径，它们的结果不同：

(a) runner 已启动之后的失败 —— packages/ptc-runtime/ptc-runtime-node/src/index.ts:281-283 用 classifyRunnerFailure(exitCode, stderr, rules) 配 sandbox-local/src/index.ts:241 的规则（allowedExitCodes: [WINDOWS_ACL_RUNNER_FAILURE_EXIT]、fatalSignatures: ['windows-acl-run: ']）⇒ 这条路已经是 sandbox-unavailable。

(b) 你这次的实际路径 —— 失败发生在宿主进程的 confine() 里，在 runner 启动之前：

sandbox-local/src/index.ts:379  →  materializeAclGrant(...)
  → :407-409  AclWriteGrant.create / add
  → grant.ts:107  grantWrite
  → acl.ts:154  throwWin32(...)   ⇒ Win32Error（不是 SandboxUnavailableError）

于是它落到 ptc-node 的兜底，被归成 worker-exit。

判据：你贴的报错里没有 windows-acl-run: 前缀 —— 那个前缀是 runner 自己的 fail() 加的（runner.ts:61-64）。没有它，就证明不是 runner stderr 那条路。

⇒ 所以修复点不是"放宽 isRunnerSpawnFailure"，而是"让 sandbox-local 把'无法承载安全描述符的根'包装成 SandboxUnavailableError"。 前者会把真正的 runner 失败一起放进来；后者才精确。建议在报告里把这条改成：

宿主 confine() 内由 GetNamedSecurityInfoW 抛出的 Win32Error 未按 sandbox-unavailable 分类，而是走了 worker-exit 兜底；建议在 ACL 授权失败处按"该根不支持安全描述符"归类。

3. read-only 不触发 —— 可从代码确证

packages/sandbox/sandbox-windows-acl/src/index.ts:196-207 与 :268-281 只在 workspace-write 路径上读/写 ACL；sandbox-local/src/index.ts:371-378 的 read-only 分支用的是 ambient tmpdir()、不带 SID。⇒ 你的"read-only 不触发"成立。

4. ⭐ 缺分支：UNC / 9P 在文档与代码里都没有条目

我换了 3 组 pattern 全部 0 命中，确认这是真缺口：

• UNC|\\wsl.localhost|9P|PathIsNetworkPath|DRIVE_REMOTE
• smb|network|remote|wsl
• ERROR_INVALID_FUNCTION|ERROR_NOT_SUPPORTED|isUnsupported（win32-abi.ts 里只有 ERROR_SUCCESS = 0 与 ERROR_LOCK_VIOLATION = 33）

并且 ffi.ts:238-274 的绑定表里连 GetDriveTypeW / PathIsNetworkPathW / WNet* 都没有 ⇒ 代码里根本没有"这个根是不是网络/9P"的判定能力。

README.md 的 Known Limitations 也没有 UNC/9P 条目（最近的两条是 :130 的 caller-owned + WRITE_OWNER、:190 的 FAT）。⇒ 文档 + 代码双缺口，这一点可以让报告更强。

平台路由只按 process.platform 走：sandbox-local/src/index.ts:160-167 的 win32: ['windows-acl']。所以"在 UNC 根上仍然选了 windows-acl"是必然的，不是选择错误。

5. 今天就能用的 workaround（比升权限轻）

切到 read-only 即可让 run_code / PTC 在这类根上恢复 —— 不读 ACL、不授权、--temp 用 ambient。不必提到 danger-full-access（那是不必要的放宽）。

另外若只是要跑命令，把工作区根从 \\wsl.localhost\… 换成盘符映射路径（或在 WSL 内用原生 Linux 路径）也能绕开 —— 因为问题出在 Windows 侧拿不到安全描述符。

6. 版本

你写 0.2.0-rc.2。沙箱后端在 rc.2 与 origin/master（= dsh-v0.2.1-alpha.2）之间逐字节相同：

git diff --stat dsh-v0.2.0-rc.2 origin/master -- \
  packages/sandbox/sandbox-windows-acl/src packages/sandbox/sandbox-local/src \
  packages/sandbox/sandbox/src packages/shell/pwsh-sandbox/src packages/shell/bash-sandbox/src
→ 空

⇒ 上述结论对你的版本与最新线同时成立，升级不解决。

7. 一条未复核项

你引的 lib/types-Cl_DXjhk.js 的 md5 与 bundle 行号 400-407 我没有下载 npm tarball 去逐字比对（文件名本身合理，package.json 的 files 含 lib/types-*.js）。但"未修"这一点已由源码侧独立证实，所以不影响结论；若你要在报告里保留那段引用，建议改用源码位置（acl.ts:150-154）以免版本漂移。