[Windows Desktop] profile 目录继承 Low 完整性标签，市场安装的含原生二进制插件无法运行

[beyondgjc]

Summary

DSH Desktop（Windows）会把 profile 目录 %USERPROFILE%\.dsh\profiles\<profile> 标成可继承的 Low 完整性标签（Mandatory Label\Low Mandatory Level:(OI)(CI)）。市场安装插件时，pnpm 在这个目录下写出的所有文件都会继承 Low，包括插件依赖的原生二进制（如 Electron）。插件激活时启动这些二进制会直接失败（Chromium exit 0x80000003），窗口/进程起不来。

影响面：任何带原生二进制的市场插件，在所有 Windows 用户上都会中招，不是单个插件的问题。插件作者目前只能在运行时自行 icacls 抬标签绕过（我们已在 dsh-agentic-pet 0.4.6 中这么做作为 workaround），但这不应由插件承担，也绕过了安装沙箱的一层 defense-in-depth。

EN: On Windows, the desktop profile directory carries an inheritable Low integrity label, so everything pnpm installs from the market inherits it — including native binaries. Plugins that ship an executable cannot start it (Chromium exits 0x80000003).

Reproduction

1. Windows 10.0.26300 x64 + DSH Desktop 0.2.0-rc.2（bundled pnpm 11.7.0 / node 24.21.0），profile desktop。
2. 从市场安装一个依赖原生二进制的插件：dsh-agentic-pet@0.4.5（npm，依赖 electron@^44.7.0，实际解析到 44.10.1）。
3. 插件激活时自动 spawn ...\node_modules\electron\dist\electron.exe <carrier>。
4. 子进程立刻退出：carrier-spawn.log 记录 child exit code=2147483651（0x80000003），宠物窗口不出现。
5. icacls 证据：

C:\Users\<user>\.dsh\profiles\desktop
  Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

C:\Users\<user>\.dsh\profiles\desktop\node_modules\electron\dist\electron.exe
  Mandatory Label\Low Mandatory Level:(I)(NW)

6. 对照实验：
   • 把 electron dist 复制到 profile 外（~\.dsh\electron-dist，Medium）→ 同一份二进制正常启动；
   • 或原地 icacls "<dist>" /setintegritylevel "(OI)(CI)M" /T（76 个文件）→ 同一份二进制正常启动。
   • 宿主进程本身是 Medium（它写的 ~\.dsh\whale598\pet-surface-url.json 是 Medium），所以 Low 不是宿主令牌造成的，而是 profile 目录的继承标签。

Current behavior

• 市场安装的插件原生二进制继承 Low，无法运行（0x80000003；低完整性也写不进 %APPDATA% 的 userData，伴随 拒绝访问 (0x5)）。
• 插件作者只能运行时自愈：ensureElectronUsable() 在 spawn 前检查 icacls，发现 Low 就抬到 Medium（dsh-agentic-pet 0.4.6，commit 946778c）。这是对安装沙箱的绕过，不应是长期方案。

Expected behavior

建议任选其一（宿主/市场侧）：

1. 插件安装（pnpm）在 Low 沙箱之外执行；或安装完成后把 profile 下新写入文件的标签恢复到 Medium。
2. 安装后对 node_modules 里的可执行文件做一次完整性标签归一化。
3. 不要给 profile 目录本身打可继承 Low；只给真正需要沙箱的工作区/工具执行目录打标签。
4. 如果“原生二进制必须保持 Low”是有意策略，请在文档中说明，并提供受支持的启动方式（例如宿主提供 Medium 的 launcher），而不是让每个插件自行 icacls。

Environment

• DSH Desktop 0.2.0-rc.2 (Windows 10.0.26300 x64), profile desktop
• pnpm 11.7.0, node 24.21.0
• Repro plugin: dsh-agentic-pet@0.4.5（npm），electron 44.10.1
• 相关：2026-11-02 的 workspace Low 事故（workspace 目录 Low → electron 0x80000003），当时的临时修复是 icacls 标 Medium；这次确认 profile 目录本身也会让市场安装的文件继承 Low。

Additional context

• 自愈代码的边界：仅 Windows、仅 npm 依赖的 electron 两个解析分支、只抬到 Medium、不碰用户显式指定的 DSH_PET_ELECTRON 路径、失败只写日志。
• 如果上游修复，插件侧的 workaround 可以删除。
• 插件仓库：https://github.com/beyondgjc/dsh-agentic-pet（修复 commit 946778c）

[beyondgjc]

更正：影响面不是"所有 Windows 用户"，Low 标签也早于市场安装

补充本机进一步排查的结果，修正上面 Summary 里的影响面描述。

1. profile 目录的 Low 标签不是市场安装造成的，也不是 DSH 的默认初始状态

• profile 目录创建于 2026-10-05。
• 授权锁 %TEMP%\dsh-acl-locks\5cd5a32d529c5556.lock（= sha256(lowercase(profileDir)) 前 16 位）创建于 2026-10-20 16:45。
• 同一分钟存在 ~/.dsh/sessions/--C-Users-beyondguo-.dsh-profiles-desktop--/…（目录名即 workspace 路径，创建于 16:44），并在 profile 下写入了 .qqbot / dshqqbot 等配置。
• ACL 上的 S-1-4-10914438-1006725775 正好等于 workspaceWriteSid("C:\Users\<user>\.dsh\profiles\desktop")（按 sandbox-windows-acl/src/workspace-sid.ts 的算法计算），说明这是 ACL 沙箱给"workspace 根"打的常驻授权（workspace SID + Everyone 删除子项拒绝 + Low 标签）。
• 对照：项目工作区的锁 9e1a82593a56b57e 是 2026-11-02 14:01（首个 pwsh），与当天的同类事故时间吻合。
• 结论：只要某个 DSH 会话把 profile 目录当成 workspace 跑过工具，这个目录就会被永久标 Low。这次市场安装只是把原生二进制写进了已经 Low 的树里，不是标签的施加者（安装前后锁时间没变）。

2. 影响面需要收窄

• 干净 profile（没有把 profile 当 workspace 跑过 sandbox 工具）不会自动继承 Low；electron 由插件在首次激活时懒安装，文件由宿主（Medium）写入，能正常启动。
• 因此受影响的是 profile 树被 workspace 授权过的用户（例如开发者在 profile 目录里开过会话/跑过 shell），不是所有 Windows 用户。
• 想请维护者确认：桌面端的插件安装/管理路径是否也会以 profile 为 workspace 跑 ACL 沙箱？ 如果是，影响面才会扩大到所有从市场安装的用户；如果否，就限于上面这类 profile。

3. 另一个对原生二进制插件普遍的风险（非 DSH 特有）

• electron 44 的 npm 包在 require('electron') 时会同步执行 install.js 下载 ~250MB；如果插件在激活路径里 require 它，会阻塞宿主事件循环，且失败时没有清晰提示。
• 我们已在插件侧改为：不在激活路径 require electron，改为解析包目录；二进制缺失时后台 spawn install.js（带进度日志、并发锁），失败时输出镜像配置提示（ELECTRON_MIRROR）。这条只是给其它带原生二进制的插件作者提个醒；DSH 若能在插件安装阶段预取/提供进度，会更稳。

上面原来的修复建议（安装后归一化标签，或不要把 profile 树当作常驻 Low 的 workspace 根）仍然成立，只是请按"profile 被授权过"这个前提来评估优先级。