【bug】Windows：工作区的 Low 完整性标签打在 DSH 自身二进制上时，桌面端无法启动、插件安装必然 EPERM（安装目录 == 工作区）

[1134478268-dev]

Summary (EN): @deepseek-ai/dsh-sandbox-windows-acl stamps Low mandatory integrity on the workspace tree. When the install directory is itself the workspace, that stamp lands on DSH's own DeepSeek Harness.exe. Windows then forces every process launched from that image to Low integrity, so the desktop client cannot start (Chromium singleton lock → ACCESS_DENIED 0x5), and plugin installation always fails with EPERM (pnpm cannot write %USERPROFILE%\.dsh\profiles\<profile>). Raising the tree back to Medium (icacls /setintegritylevel (OI)(CI)Medium /T) restores both.

---

环境

项	值
DSH 桌面客户端	0.2.0-rc.2（Windows x64，Electron）
操作系统	Windows 10 专业版 Build 19045，NTFS
安装目录	D:\dsh
工作区	D:\dsh（与安装目录相同）
DSH_HOME	C:\Users\<user>\.dsh
profile	desktop

摘要

一次正常的沙箱初始化，可以让 DSH 把自己锁死在「无法启动 + 无法安装插件」的状态。

工作区被打上 Low 强制完整性标签后，因为安装目录就是工作区，这个标签同时落在 DSH 自己的二进制上。于是：

1. 桌面客户端无法启动 —— 从带 Low 标签的映像启动的进程整体被降为 Low，写不了隐式 Medium 的 userData 目录，Chromium 单例锁创建失败，秒退；
2. 插件安装必然失败 —— 即使应用能起来，它的 shell / pnpm 子进程同样是 Low，写不了同样位于 C 盘用户目录的 profile。

现象 A：应用无法启动

启动约 15 秒后退出，没有新的崩溃日志（在 Chromium 初始化早期就退出）。早期日志：

Lock file can not be created
拒绝访问。 (0x5)

排查过程中确认过：userData 目录权限正常、目录里没有残留锁文件、我们自己写该目录完全正常，但只有 DSH 进程被拒。全新临时 --user-data-dir 也一样，说明不是某个目录的问题。

现象 B：插件安装 EPERM

在桌面客户端的「插件」页面安装 dsh-whale-widget：

$ pnpm add dsh-whale-widget --registry=https://r...        退出码 4294963248
[EPERM] EPERM: operation not permitted, open
  'C:\Users\<user>\.dsh\profiles\desktop\_tmp_25868_797aa22825fb864bf9562d9ac6e8418e'

命令行同样失败，说明与插件页面无关（顺带确认：dsh plugin --profile desktop … 不会被 profile "desktop" is managed exclusively by the Electron application 拦下，它一路走到文件锁）：

> dsh plugin --profile desktop add dsh-whale-widget
Error: EPERM: operation not permitted, open
  'C:\Users\<user>\.dsh\profiles\desktop\package.json.lock'
    at async withFileLock (.../@deepseek-ai/dsh-atomic-write/lib/index.js:195:4)
    at async runPlugin    (.../@deepseek-ai/dsh/lib/plugin-BGnVfe_D.js:90:41)
    at async runCli       (.../@deepseek-ai/dsh/lib/bin.js:236:17)

根因

工作区树带 Low 强制完整性标签：

icacls D:\dsh
    Everyone:(CI)(DENY)(S,DC)
    S-1-4-770832337-362390069:(OI)(CI)(W,D,DC)
    BUILTIN\Administrators:(I)(F)
    ...
    Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

因为 D:\dsh 既是安装目录又是工作区，DSH 自己的二进制继承了同一个标签：

icacls "D:\dsh\DeepSeek Harness.exe"
    Mandatory Label\Low Mandatory Level:(NW)

于是从它启动的进程被整体降为 Low（实测）：

> whoami /groups | findstr /i mandatory
Mandatory Label\Low Mandatory Level    Label    S-1-16-4096

Low 进程受 no-write-up 约束，不能写 Medium 对象。而 userData（%APPDATA%\@deepseek-ai\dsh-desktop）和 profile（%USERPROFILE%\.dsh\profiles\desktop）都是隐式 Medium：

写 D:\dsh                                  → OK
写 C:\Users\<user>\.dsh                    → Access to the path ... is denied.
写 C:\Users\<user>\.dsh\profiles\desktop   → Access to the path ... is denied.
写 C:\Users\<user>\AppData\Local\pnpm      → Access to the path ... is denied.
写 D:\dev                                  → Access to the path ... is denied.

关键点：DACL 完全正常（Administrator:(F)、无 deny 项、目录无只读属性、所有者正常），拒绝 100% 来自完整性级别。这也是排查时最容易走偏的地方——很容易误判成「杀软拦截」或「文件被瞬时占用」。

同一个机制还解释了为什么「宿主进程能写、子进程不能写」：宿主是 Medium，而 shell / pnpm 子进程是 Low。

临时修复（已验证）

把安装目录树提升回 Medium：

icacls "D:\dsh" /setintegritylevel (OI)(CI)Medium /T

前后对比（同一台机器、同一会话）：

检查项	修复前	修复后
shell 进程完整性（whoami /groups）	Low (S-1-16-4096)	Medium (S-1-16-8192)
写 %USERPROFILE%\.dsh	denied	OK
写 %USERPROFILE%\.dsh\profiles\desktop	denied	OK
写 AppData\Local\pnpm	denied	OK
写 D:\dev	denied	OK
桌面客户端启动	秒退（0x5）	正常，7 个进程常驻
dsh plugin --profile desktop add dsh-whale-widget	EPERM	exit 0，2.5s 完成

插件随后正常安装并加载（dsh.profile.bundles 追加成功，/dsh-whale/* 路由注册成功）。

建议修复

1. 不要把 Low 完整性标签施加到承载 DSH 自身二进制的目录上。 让受限子进程能写入工作区，单靠 ACL 授权（S-1-4-… 写 ACE）就够了；Low 标签是进程级降级，副作用会传染给从该目录启动的任何映像——包括 DSH 自己。这是本报告与 [Bug Report] windows-acl: Low integrity label (and allow ACE) not applied to existing subfolders, so the confined child can write only the workspace root #9559 的关键区别：[Bug Report] windows-acl: Low integrity label (and allow ACE) not applied to existing subfolders, so the confined child can write only the workspace root #9559 是「少写一个目录」，这里是「应用启动不了」。
2. 如果必须使用 Low 标签，跳过安装目录：比较工作区与被执行映像所在目录（process.execPath）即可判断；至少应在启动时检测「自身 exe 带 Low 标签」并给出明确诊断，而不是静默秒退。
3. 插件管理器的 pnpm 不应被沙箱降级，或应对 profile 目录做与工作区同等的沙箱授权。profile 位于 %USERPROFILE%\.dsh，在任何工作区配置下都不会落在工作区里，所以桌面端的插件安装目前必然 EPERM。
4. 诊断改进：EPERM / 0x5 / 0xC0000142 这类失败应报告为「沙箱拒绝/沙箱不可用」，并附上当前进程完整性级别与目标对象标签。目前的表现会让人去查杀软、查占用、查 ACL，全都查不出东西。

与已有报告的关系

• [Bug Report] windows-acl: Low integrity label (and allow ACE) not applied to existing subfolders, so the confined child can write only the workspace root #9559 — Low 标签与 allow ACE 没有传播到已存在的子目录，受限子进程写不了工作区子目录。本报告是同一机制的另一个后果，触发条件是安装目录与工作区重合。
• Bug report: Windows desktop shell commands fail with 0xC0000142 under workspace-write #9548 — workspace-write 下 shell 子进程 0xC0000142。本报告现象 A 与它相邻（都指向 Electron 宿主 + 受限令牌），但成因不同：这里是映像文件本身带 Low 标签导致进程降级，与 CREATE_NO_WINDOW / 控制台无关。

复现概要

1. 把 DSH 安装到 D:\dsh，并让某个会话的工作区也是 D:\dsh；
2. 让沙箱完成一次 workspace-write 初始化（触发标签写入）；
3. 观察 icacls D:\dsh 出现 Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)，且 D:\dsh\DeepSeek Harness.exe 继承该标签；
4. 重启客户端 → 秒退（0x5）；此时 whoami /groups（沙箱内）为 Low；
5. 在此状态下尝试安装任意插件 → pnpm EPERM；
6. icacls "D:\dsh" /setintegritylevel (OI)(CI)Medium /T → 启动与插件安装均恢复。

报告已脱敏：用户名与主机名以 <user> 占位，未包含凭据、密钥或会话内容。

[argszero]

This is the other face of the mechanism reported in #9559 thirty minutes before your post, and the reason it bites is structural: the grant is standing.

1. Why the standing label reaches the host's own binary. The write grant materializes the Low label on the workspace root as an inheritable ACE (buildLowLabelAcl in sandbox-windows-acl/src/acl.ts calls AddMandatoryAce(..., SUB_CONTAINERS_AND_OBJECTS_INHERIT, …)), and it is deliberately left in place when the session ends — sandbox-windows-acl/README.md § Known Limitations says so in as many words: "A standing Low label outlives DSH and widens the tree for other Low-integrity processes", with the stated reason that revoking it per session would re-propagate the whole tree on every provision. Inheritance reaches a child at creation, so the binary in your report carries the label because it was created inside an already-labelled tree — an install or an update into D:\dsh while the label stood. The mirror image is #9559: a child created before the label exists keeps nothing. Either way the label ends up on the image, and Windows forces every process launched from that image to Low — your whoami /groups line is the direct evidence.

2. The repository-side gap. The sandbox has exactly this class of protection for one directory and not for this one. assertTempRootOutsideWorkspace (sandbox-windows-acl/src/path-boundary.ts, called from sandbox-local/src/index.ts before any grant) refuses a workspace that contains the private temp root — a deliberate refusal with its own runner-side producer. Nothing analogous looks at the harness's own installation: git grep execPath across packages/sandbox/*/src returns only the source-loader pin in sandbox-local/src/index.ts, and no path check compares the workspace root with the running application's directory. So the configuration you used is accepted silently, and the damage lands on the host rather than on the sandboxed child — which is why the symptom reads as "DSH broke itself" instead of as a sandbox denial. As far as the package's tests go, yours is the first measurement of it.

3. What your evidence pins down. The write table is a good discriminator: D:\dsh writable, everything outside it denied, and a clean DACL — no ACE problem, no antivirus, no transient lock, only the integrity level. The same single cause also explains the host/child asymmetry you observed: the host process is Medium, its shell and pnpm children are Low.

4. Where the fix belongs. Also core, and there are two directions for the maintainers to weigh: refuse the configuration the way the temp-root case is refused (a workspace that contains the harness installation), or exclude the harness's own tree from the label. Your workaround (icacls "D:\dsh" /setintegritylevel (OI)(CI)Medium /T) restores the host; it is worth recording that it is a relabel of the whole tree, object by object, not a restoration of the previous state — the same shape of operation as the removal procedure a reporter measured for #7846, where the tree comes back at an explicit Medium level rather than unlabelled.

5. From this side. @argszero/cordis-plugin-sandbox-grant-advisor documents what the standing grant leaves in a tree after the session — the label and the capability ACE — and carries the user-measured removal path for it. Your configuration is the shape that turns that residue into a host failure, so I have recorded it as a candidate pre-flight check for the advisor: the workspace root containing the running application's own directory. npm: https://www.npmjs.com/package/@argszero/cordis-plugin-sandbox-grant-advisor

Thanks for the four-way write matrix and the two icacls listings — together they rule out the three explanations that would otherwise come first (DACL, antivirus, lock residue).