Windows 沙箱把工作区整棵树永久标为 Low integrity，导致工作区内的可执行文件在沙箱外运行时无法写/删用户目录（例：Vite/esbuild 构建报 Access is denied）

[zhangtong-arch]

环境

• DeepSeek Harness 桌面版 0.2.1-rc.2（app.asar 构建于 2025-10-17，安装于 2025-10-20）
• Windows 11 10.0.26200 x64
• Profile：desktop（dsh-base + dsh-web-app）
• 涉及模块：@deepseek-ai/dsh-sandbox-windows-acl、@deepseek-ai/dsh-sandbox-local、@deepseek-ai/dsh-sandbox-policy

现象

用 DSH 在这个工作区以默认权限（workspace-write / 工作区内修改）跑过一次 agent 之后，退出 DSH、在普通终端里构建该项目必然失败。本例是 Electron + Vite 项目：

✗ Build failed in 9.50s
 ERROR  [vite:esbuild-transpile] remove C:\Users\<user>\AppData\Local\Temp\esbuild-<hash>: Access is denied.

pnpm start:dev 在主进程 SSR 构建阶段中断，项目自身没有任何改动。

复现步骤

1. 用 DSH 桌面版打开一个 Node 项目目录，保持默认权限（工作区内修改），让 agent 执行任意会写文件的命令（触发沙箱 provision）。
2. 退出 DSH，在普通终端（Medium 完整性）执行下面的脚本（放在同目录，>1 MiB 输入会触发 esbuild 的临时文件路径）：

// repro.js
const esbuild = require('./node_modules/esbuild');
const big = 'console.log(1);\n'.repeat(70000);
esbuild.transform(big, { loader: 'js', sourcefile: 'big.js' }).then(
  (r) => console.log('OK', r.code.length),
  (e) => { console.error('FAIL:', e.message); process.exit(1); }
);

FAIL: remove C:\Users\<user>\AppData\Local\Temp\esbuild-<hash>: Access is denied.

同一份 esbuild.exe 复制到 %TEMP%（Medium）后再跑同样的脚本则成功。对照实验：

esbuild 二进制	完整性级别	>1 MiB transform
工作区内原文件（DSH 打过标）	Low	FAIL remove ...: Access is denied.
复制到 %TEMP% 后手工标 Low	Low	FAIL，同一错误
复制到 %TEMP%（默认 Medium）	Medium	OK

根因

@deepseek-ai/dsh-sandbox-windows-acl 在 provision workspace-write 时，对工作区根目录做三处常驻改动（模块注释中明确为设计行为：standing、不随会话撤销）：

1. Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)（可继承的完整性标签）；
2. 对 world SID 拒绝 FILE_DELETE_CHILD（ACL 中表现为 Everyone:(CI)(DENY)(DC)）；
3. 对由工作区路径派生的 capability SID 授予 W,D,DC（S-1-4-<sha256 派生>）。

由于标签可继承：

• 整个已有子树被递归标成 Low。本例中 2025-10-14 安装的 node_modules/@esbuild/win32-x64/esbuild.exe（早于 DSH 本次使用）也被标成 Low；
• 由于 pnpm 使用硬链接，标签还会顺着硬链接改到 pnpm store 里共享的同一文件对象，从而影响同机其他项目；
• 之后从普通终端（Medium）运行构建时：Node 把 >1 MiB 输入写入 %TEMP%（Medium），而 esbuild.exe 因镜像带 Low 标签而以 Low 完整性运行，os.Remove 返回 ERROR_ACCESS_DENIED → 构建失败。

该 SID 可确认来自 DSH 而非本地规则，算法即 workspaceWriteSid：

sha256("C:\\Users\\<user>\\Desktop\\home\\project\\<repo>") 前 8 字节
// 两个子授权取 30 位后 → S-1-4-40252865-1043631312
// 与 ACL 中的 SID 完全一致

影响

• 工作区内任何被 spawn 的可执行文件（构建工具、打包器、测试 runner、Python 解释器等）在沙箱外都会以 Low 完整性运行：不能写用户目录（%TEMP%、%APPDATA%、日志/缓存），不能删除沙箱外文件。
• 症状表现为"某个工具莫名 Access is denied"，与 DSH 的使用之间没有显式关联，用户极难自行定位。
• 标签常驻且可继承（同卷移动目录也保留），只在工作区再次被 DSH provision 时命中 exact-ACE/exact-deny/exact-label skip，不会自动修复。
• 文档目前只说明"手工 icacls 无法回收这些 ACE（ERROR_NONE_MAPPED, 1332），请通过本模块回收"，但没有向用户提供可用的回收入口。实际处置只能把 Low 标签改回 Medium（icacls <workspace> /setintegritylevel (OI)(CI)medium /T，本机 92,025 个文件、约 70 秒），ACL 里的 capability ACE 和 FILE_DELETE_CHILD deny 仍残留。

期望行为 / 建议

1. 提供正式的 teardown 入口：如 dsh sandbox revoke --workspace <path>，或设置中的"重置工作区权限"，能撤销 Low 标签、capability ACE 与 FILE_DELETE_CHILD deny，并递归处理子树；文档给出可直接复制的命令。
2. 降低常驻副作用：
   • 不要把标签传播到与工作区外共享的文件（硬链接）上，或在撤销时一并还原；
   • 或考虑在 Windows 上改用不会永久改写用户目录安全描述符的隔离机制（如 AppContainer / 受限 token + 仅授 capability SID），去掉"整树 Low 标签"这一设计。
3. 显式告知：首次以 workspace-write 运行前提示"将在该工作区写入常驻 ACL/完整性标签，会影响在此目录内运行的其他开发工具"，并给出撤销方式。
4. 诊断：检测到工作区已带 Low 标签、而当前命令以更高完整性运行时，给出可操作的警告；或提供"检查/清理工作区沙箱残留"命令。

相关讨论

• [Windows Desktop] profile 目录继承 Low 完整性标签，市场安装的含原生二进制插件无法运行 #11964《[Windows Desktop] profile 目录继承 Low 完整性标签，市场安装的含原生二进制插件无法运行》——同一种"可继承 Low 标签"设计的 profile 目录侧表现；本帖是 workspace 根目录侧的表现（影响工作区内的构建工具，并通过硬链接波及 pnpm store），两者可以合并评估，但复现与影响面不同。

临时绕过（供维护者参考）

• 改用「完全权限」（danger-full-access）的会话不会触发 provision，也就不会打标；
• 已被打标的工作区可手工恢复：icacls <workspace> /setintegritylevel (OI)(CI)medium /T（可继承标签改回 Medium；capability ACE 与 deny 仍需模块自身回收）。

证据摘录

> icacls <workspace>
Everyone:(CI)(DENY)(DC)
S-1-4-40252865-1043631312:(OI)(CI)(W,D,DC)
Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

> icacls <workspace>\node_modules\@esbuild\win32-x64\esbuild.exe
Mandatory Label\Low Mandatory Level:(I)(NW)

> fsutil hardlink list ...\node_modules\@esbuild\win32-x64\esbuild.exe
\Users\<user>\AppData\Local\pnpm\store\v10\files\03\e881...-exec
\Users\<user>\Desktop\home\project\<repo>\node_modules\@esbuild\win32-x64\esbuild.exe

可信度说明

• 根因经 A/B 对照确认（Low 副本必现同一错误；Medium 副本成功），非推测；
• 触发时间为本机 2025-11-02 23:34 左右开始的一次 workspace-write 会话，之后未再被 DSH 重新打标（手工改回 Medium 后保持至今）。