Bug:Windows ACL 沙箱在其缓存的私有临时目录被回收后永久失效

[Guojin0826]

摘要

Windows ACL 沙箱 provider(@deepseek-ai/dsh-sandbox-local)会为每个活跃的
(sessionId, workspaceRoot) 组合创建一个随机私有临时目录并缓存在内存中。之后每次
workspace-write 调用都会返回这个缓存条目,却不检查该目录是否仍然存在。只要操作系统在
provider 存活期间回收了这个目录(存储感知 / 磁盘清理 / 杀软都可能),那么每一条
workspace-write 命令——因此实际上等于所有命令——都会失败,直到 DSH 进程重启。

失败时是安全关闭(fail-closed)的:沙箱层拒绝在无沙箱的情况下运行命令,所以这是一个
可用性缺陷,而非沙箱逃逸。

环境

• @deepseek-ai/dsh-sandbox-local、@deepseek-ai/dsh-sandbox、@deepseek-ai/dsh-sandbox-windows-acl — 0.1.1-rc.2
• Windows 10/11(NTFS)

复现步骤

1. 启动 DSH,随便跑一条 workspace-write 命令(这会物化一次临时授权)。
2. 删除 provider 的私有临时目录,例如 C:\Users\<user>\AppData\Local\Temp\dsh-RW1t41
   —— 这正是存储感知对过期 %TEMP% 条目所做的事。
3. 再跑一条 workspace-write 命令。

此后每条命令都会失败,直到 DSH 重启。

观察到的报错

sandbox mode "workspace-write" is requested but no sandbox backend is usable on this host; ...
Runner failure: windows-acl-run: --temp is not an existing directory: C:\Users\<user>\AppData\Local\Temp\dsh-RW1t41

每次重试出现的都是同一个目录名——证明是过期缓存,而非新建目录。

根因

@deepseek-ai/dsh-sandbox-local/lib/index.js 中的 materializeAclGrant():

const key = JSON.stringify([String(sessionId), workspaceRoot]);
const existing = this.tempCapabilities.get(key);
if (existing !== void 0) return existing;   // <- 没有存在性检查

缓存里的 capability.dir 随后作为 --temp 传给运行器,而运行器一上来就校验它
(@deepseek-ai/dsh-sandbox-windows-acl/lib/runner.js),目录被删掉后就会失败。

建议修复

在复用缓存能力(capability)之前,先检查它的目录是否仍然存在;若已不存在,丢弃这个过期
条目并继续往下重建。existsSync 在该文件顶部已经 import,grant.dispose() 也是本函数
自身错误处理路径里已经在用的清理调用。

 		const existing = this.tempCapabilities.get(key);
-		if (existing !== void 0) return existing;
+		if (existing !== void 0) {
+			if (existsSync(existing.dir)) return existing;
+			try {
+				existing.grant.dispose();
+			} catch (cleanupError) {
+				// best-effort: the dir is gone, so its ACEs are gone with it
+			}
+			this.tempCapabilities.delete(key);
+		}

验证

• 对打补丁后的文件运行 node --check 通过(exit 0)。
• 人工复查确认:existsSync、capability.dir、grant.dispose()、以及
  this.tempCapabilities(一个 Map)都齐全且一致。

[argszero]

在 49a606bc（当前 master, 0.1.2-alpha.5）上把你的根因与补丁逐行验证——bug 在 master 原样存在, 补丁形状正确, 可以直接落。几条从当前源码读出的补充:

逐点确认（master 行号）

• 缓存复用无存在性检查: packages/sandbox/sandbox-local/src/index.ts materializeAclGrant() :413-414, 与你的 rc.2 引文逐字一致:

  const existing = this.tempCapabilities.get(key)
  if (existing !== undefined) return existing   // ← 无 liveness 检查

  bug 从 rc.2 一路到 alpha.5 未变。且 :390-395 的 doc 注释把错误假设写进了设计: "The temp directory is random … materialized once per provider lifetime"、"A fresh provider always chooses a new path; crash residue therefore cannot collide"——设计默认"provider 生命周期内目录必在", 而 OS 托管的 %TEMP% 恰恰是外部清理器(存储感知/磁盘清理/杀软)按定义可回收的空间, 两者冲突。

• 运行器侧校验如实: packages/sandbox/sandbox-windows-acl/src/runner.ts requireDirectory('--temp', parsed.temp) :105-111——注释明说 "a provider bug that passes a bogus root must fail loudly at the runner boundary"。所以失败链 = provider 返回过期缓存 → runner 边界 loud fail → 你看到的 --temp is not an existing directory。每命令同目录名 = 缓存永续, 你的推断对。

• 你补丁的每个元素都齐: existsSync 已在 :24 import ✓; capability 记录 { dir: tempDir, writeSid: tempSid, grant }（:439, dir 字段名正确）✓; grant.dispose() 正是本函数创建失败路径 :425 已在用的清理调用 ✓; dispose+delete 后代码自然落入下方既有的 mkdtempSync 重建路径, 不需要新增任何创建逻辑 ✓。

一个结构对照: agentless 路径天然免疫, 恰好证明修法方向

windowsAclRunnerArgv() 里 sessionId 缺席的分支（:358-366）把 --temp tmpdir() 根目录交给运行器, 由运行器每次调用自建自删随机私有子目录——每次新鲜, 永不缓存, 外部清理打不中。只有 session 作用域的缓存 capability 中招。对照本身说明: 对 OS 管理的外部可回收路径,每次使用的新鲜性 > 跨调用缓存; 你的修法（复用前验活, 死了丢弃重建）是让缓存路径具备同等韧性的正确最小补丁。

家族背景: 这是同一轴的第 5 个成员

"外部 OS 临时目录清理打断运行中的 dsh" 此前已有 4 报: #3190/#3203（spill 目录被外部删除 → spillAll openSync/writeSync 无 try/catch → uncaughtException 整进程死）、#5175（Linux usrquota 配额满同款）、#5332（Windows 侧 8325 个孤儿 dsh-subprocess-* 目录堆积 20GB）。#5477 是新机制: 前 4 报是"写入/清理路径没抗外部删除", 这报是"跨 provider 生命周期缓存的外部路径句柄, 复用时从不验活"。共同教训值得固化成一条审计规则: 任何持有 %TEMP%/tmpdir() 派生路径超过单次调用的缓存, 都必须 (a) 复用时验证存在性 + (b) 自愈重建——因为外部清理器把 temp 当可回收空间是它们的存在意义, 不是 bug。同类缓存（其他包的临时 profile/子目录句柄）建议按同一 lens 过一遍; 你若愿意, 这可以是一个独立的小审计 PR 的由头。

其它

• 严重度框定同意: 纯可用性缺陷, fail-closed 无逃逸面。补一句——失败文案 "no sandbox backend is usable on this host" 对根因有误导性（实际是 stale 缓存不是后端缺失）, 你的补丁顺带消灭这个诊断陷阱。
• 回归测试建议: provider 内两次 materializeAclGrant（或两次 workspace-write argv 构建）之间删除缓存目录, 断言第二次返回新目录且运行器参数可执行——正好覆盖你补丁的丢弃+重建分支。sandbox-local 现有 windows-acl 测试夹具可直接挂。
• 若走 PR: 这是行为收敛 + 自愈, 无兼容面, pre-release 窗口内可直落。

[argszero]

补一个重要的家族修正——#5477 是 #3203 的第二次独立报告, 同一缺陷, 不是新机制（我上一条回复的家族归类有误, 以此为准）:

#3203（MMiao79, 2026-08-18, rc.7 源码）报的正是这个 bug: materializeAclGrant 缓存命中无存在性检查 → requireDirectory('--temp') runner 边界 fail-loud → 所有沙箱命令 fail-closed 直到重启。同一文件同一段（rc.7 时 :392-443, master 现 :392-441, 缓存返回行 :413-414 逐字未变）, 我当时也验证并背书了作者的同形补丁（provider 侧缓存命中时验活重建, 见 #3203 讨论串 comment-18070748）。两报相隔两个发布（rc.7 → alpha.5）, 缺陷原样存活——这恰恰是 #5477 的价值: 证明该修复两轮未落地, 而不是"新机制"。

修正后的家族全景（"外部 temp 清理打断运行中 dsh", 崩坏侧 3 机制 + 堆积侧）:

• 机制 A — spill 写入路径无抗外部删除: [Bug] dsh web crashes with ENOENT when external temp cleanup removes the subprocess spill dir #3190 (ENOENT) + [Bug] OutputCollector.spillAll writeSync is uncaught: EDQUOT/ENOSPC kills the whole dsh web host #5175 (EDQUOT), spillAll openSync/writeSync 无守卫 → uncaught 整进程死。
• 机制 B — windows-acl 缓存 capability 不验活: windows-acl 沙箱临时目录被外部清理后不会自动重建，沙箱命令持续报错 #3203 + Bug:Windows ACL 沙箱在其缓存的私有临时目录被回收后永久失效 #5477（本串）, provider 生命周期内缓存 %TEMP% 私有目录句柄, 外部回收后每命令同目录名 fail。
• 堆积侧: 【BUG反馈】8,325个临时目录差点把我的C盘干爆炸了（附修法，官方看一眼啊） #5332 (8,325 孤儿目录 20GB)。

上一条里"#3203 是 spill 路径"的说法错误, 抱歉——spill 路径是 #3190/#5175。机制 B 现在有两份独立报告 + 两份同形补丁背书, 修复优先级应该更高了: 这是纯可用性 + 误导性报错 + 跨两版未修, 而补丁极小且无兼容面。若走 PR, 建议在补丁里顺带引用 #3203/#5477 两份报告。