[Bug] Windows：沙箱给工作区根目录盖 Low 完整性标签后，目录内的 .bat/.cmd/.exe 双击弹「无法验证发布者」

[ljingqi]

---

简短描述：

这个问题都是更新完0.17后才出现的，在安全设置里现在有两个未知账户，一个是0.16的，有所有权限，一个是0.17的，只有读取和写入权限，现在只能开full acces修改项目的代码，但这么做太危险了。

环境

• Windows 11 25H2，build 26200.9457（x64）
• dsh 0.1.7-rc.1（源码方式构建/运行，HEAD 46a7f68）；Node v24.20.0
• 工作区：<project-root>、<workspace-B>（见 ~/.dsh/storages/workspace.json）
• 对照：同机、同一份 dsh、更新前就已授权过的项目 <control-workspace>（最后一次 dsh 会话 2026-09-23 10:27）不出现本问题

现象

更新到 0.1.7 之后，工作区根目录里的启动器（启动续传.bat、启动监控.bat 等）双击时弹出（文案大意）：

打开文件 - 安全警告
无法验证发布者。是否确定要运行此软件？
发布者: 未知发布者        类型: MS-DOS 批处理文件

点「运行」后程序正常；但每次双击都要确认。目录内其它类型（.py、.md）不弹，因为它们交给编辑器而不是由 shell 启动。

已排除的常见原因

• 不是 Mark of the Web（来自 Internet）：对两个工作区全部文件遍历备用数据流，除 :$DATA 外没有任何 Zone.Identifier（方法已用临时文件自检）。属性页里也没有「解除锁定」可点。
• 与文件内容、编码、是否签名无关：把启动器换名字、换编码、重写内容都无效。
• 与权限模式、审批策略无关：标签是授权时写在目录上的，不随会话的权限模式变化。

根因

d5ad3baeb5（fix(sandbox): confine Windows deletes with a Low integrity label，2026-09-19）为堵住 cmd /c del 的父目录删除逃逸，让每次授权都在一次 SetNamedSecurityInfoW 里给被授权根目录加一条可继承的 Low 强制完整性标签（S-1-16-4096、SYSTEM_MANDATORY_LABEL_NO_WRITE_UP、OI|CI）。

目录标签一旦可继承，目录内每一个文件（含启动器）都会物化成 Low；而 shell 在启动 Low 完整性的可执行文件前会插入上面的「无法验证发布者」确认框。这是标签的必然副作用，与启动器本身无关。

实测证据（icacls，同一台机器同一份 dsh）：

对象	标签	双击启动器
<project-root>（更新后授权）	Mandatory Label\Low Mandatory Level:(OI)(CI)(NW) + Everyone:(CI)(DENY)(DC)	弹窗
<project-root>\启动续传.bat	Mandatory Label\Low Mandatory Level:(I)(NW)（继承来的）	弹窗
<workspace-B>（更新后授权）	同上	弹窗
<control-workspace>（更新前授权，无 Low 标签）	只有旧形态的能力 SID ACE，无 Mandatory Label 行	正常

时间线也对得上：0.1.7-rc.1 于 2026-09-23 发布 → 当晚更新 → 2026-09-24 08:34 / 10:09 两个工作区先后被授权（~/.dsh/storages/workspace.json）→ 症状出现；<control-workspace> 自 09-23 10:27 起没有再被授权，所以保持旧形态。

复现

1. 在任意目录放一个 run.bat；
2. 把它作为工作区连接，并执行一次 workspace-write 的工具调用（触发授权）；
3. icacls run.bat → 出现 Mandatory Label\Low Mandatory Level:(I)(NW)；
4. 在资源管理器里双击该 run.bat → 弹「无法验证发布者」；
5. 换一个从未被本项目授权的目录做同样操作（不执行第 2 步）→ 不弹。

影响面

• 所有把项目启动器放在工作区根目录、习惯双击启动的 Windows 用户；社区里大量 Windows 一键包 / 桌面壳（DeepSeek Harness 桌面一键包：解压双击即用，免装任何环境（Windows） #419、做了一套免装 Node 的 dsh 安装包：mac 双击 DMG / Windows exe（非官方） #414、[Show and tell] Harness Desktop — Windows client with themes for the official Web UI #769、[Show and tell] DeepSeek Harness Desktop — a self-contained Windows app #904、建议：安装完成后自动在桌面创建快捷方式，双击即可启动 Web 模式 #1168）正是这种用法，双击是他们唯一的入口。
• 工作区内的 .exe 工具（例如随项目分发的 tools\rakaly.exe）同样被波及。
• 对用户而言「未知发布者」是很强的安全信号，容易让人以为项目被篡改。

尝试的修复办法

本地提交 f6698853f3：fix(sandbox): exempt a granted root's launchers from the inherited Low label。

做法：每次授权结尾（完整应用路径 与 hasExactGrant 跳过路径都要跑——常驻工作区授权每次都走跳过路径，且授权之后新建的启动器会继承目录标签），给授权根顶层的 .bat / .cmd / .exe 各写一条显式、信息性的 Medium 标签，覆盖继承来的 Low：

// 顶层启动器：显式、信息性 Medium（policy 0、不继承），压过目录的继承 Low
function rootLauncherPaths(path: string): string[] {
  try {
    return readdirSync(path, { withFileTypes: true })
      .filter(entry => entry.isFile() && ROOT_LAUNCHER_EXTENSIONS.includes(extname(entry.name).toLowerCase()))
      .map(entry => join(path, entry.name))
  } catch {
    return [] // 列表读不到就保持 Low，不因此让授权失败
  }
}

function exemptRootLaunchers(api: Win32Bindings, path: string): void {
  const pending = rootLauncherPaths(path).filter(launcher => launcherVerdict(api, launcher) === 'relabel')
  if (pending.length === 0) return
  const medium = createWellKnownSid(api, abi.WinMediumLabelSid)
  try {
    const labelAcl = buildLabelAcl(api, medium, abi.NO_INHERITANCE, abi.SYSTEM_MANDATORY_LABEL_NO_POLICY, 'Medium launcher label')
    try {
      for (const launcher of pending) {
        api.setNamedSecurityInfoW(launcher, abi.SE_FILE_OBJECT, abi.LABEL_SECURITY_INFORMATION, null, null, null, labelAcl)
      }
    } finally { api.localFree(labelAcl) }
  } finally { api.localFree(medium) }
}

设计要点：

• 不缩小沙箱边界：用的是 SYSTEM_MANDATORY_LABEL_NO_POLICY（策略位 0）——只记录身份，不附加强制限制，受限子进程对这些文件的写权限完全由能力 DACL 决定，与之前一致；目录上的 Low 标签、Everyone 删除拒绝、能力 ACE 一律不动。
• 不覆盖调用方已有的显式标签（三态判定 keep / preserve / relabel），也不会动 SACL 里的审计项。
• 只扫根目录自身一层：不付「全树重写描述符」的代价；子目录里的可执行文件保持继承 Low（如需覆盖可另议）。
• 一个容易踩的坑：Medium 的 RID 是 0x2000（S-1-16-8192），S-1-16-16384 是 System；我第一版测试常量写错，被单测直接抓出来。
• 写完整性标签要对象上的 WRITE_OWNER（标签住在 SACL 里）：本机隔离实验里，单独授 TakeOwnership 就能写、只授 WRITE_DAC/READ_CONTROL/Modify 一律 Access is denied（详见下一节）。所以豁免必须放在授权路径内部执行——授权成功本身就说明该上下文对根目录持 WRITE_OWNER，而那条 ACE 会继承到文件上，豁免才写得进去；工作区 DACL 只授 Modify 时，两者都会失败（见下一节的边界说明）。

验证：

• packages/sandbox/sandbox-windows-acl 全包 14 文件 / 169 测试 PASS，其中新增 tests/root-launcher-exemption.spec.ts 5 项（apply 路径、跳过路径、非启动器不受影响、已有显式标签不被改写、无启动器时不写描述符）。
• tsc -b tsconfig.host.json、oxlint、verify-agent-note-format / verify-md-wrap / verify-md-links / verify-translation-pairing 全通过；包 README 与 2026-09-19 那条 Agent Note 的中英双侧 + .i18n.yaml 已同步。
• pnpm run build 成功（构建记录指向 f669885）。
• （可选）重启客户端后双击启动器的现场 A/B 截图：写入显式 Medium 之前弹、之后不弹

补丁的已知边缘（供评审）

• 撤销授权不回收文件上的标签：revokeWrite 只清目录标签，根目录顶层启动器上那条显式 Medium 会留下。这是有意的——它与调用方自己 icacls 打的标签形状相同，按形状删就会误伤调用方的设置（keep 判定正是为此存在）；代价是文件标签比授权长寿。
• 会话中途新建的启动器仍是 Low：豁免只在 provision 时跑，之后 agent 生成或用户拷入的启动器要等下一次授权（下一次开会话）才被修。这条会写进 README 的用户可见说明。
• 只覆盖根目录顶层：子目录里的可执行文件（如 tools\*.exe）仍是继承 Low，双击照旧确认一次。

另一条相关缺陷：workspace-write 授权不生效（同一个 WRITE_OWNER 门）

同一台机器上还有第二个症状，它和上面那个弹窗共用同一道门。

现象：会话按「工作区内写入」授权后，工作区里的写入仍被拒。dsh 的 Windows 沙箱是 fail-closed 的——provisioning 失败时命令在启动前就被整体拒绝，所以用户看到的是「权限设了没用／沙箱账户在工作区里没有权限」。

实测（直接调用 dsh 自己的 ACL 模块复现 provisioning 这一步）：

grantWrite(<project-root>)                    -> SetNamedSecurityInfoW failed (Win32 5)
grantWrite(<project-root>\_acl_probe_scratch) -> SetNamedSecurityInfoW failed (Win32 5)

根因：根目录的 DACL 里没有一条给当前用户的 ACE。 <project-root>（以及同类数据盘目录）上，用户的访问权来自继承的 NT AUTHORITY\Authenticated Users:(OI)(CI)(M)——只有 Modify，没有 WRITE_OWNER；所有者虽然是用户本人，但所有者隐式只带 READ_CONTROL 与 WRITE_DAC，补不上这一位。合并应用同时写 DACL 与 SACL 标签，标签那一步要 WRITE_OWNER，于是整个 SetNamedSecurityInfoW 返回 Win32 5，fail-closed 再把「写不进标签」放大成「这个工作区不能用」。模块 README 自己就写了「DACL 只授予 Modify 的目录现在会大声失败」——本机正是这一类，而且是 Windows 数据盘上最常见的形态：

<project-root>  Everyone:(CI)(DENY)(DC)
          S-1-5-21-…:(OI)(CI)(M)   ← 非本机 SID，未解析
          S-1-4-<capability-SID>:(OI)(CI)(M,DC)   ← dsh 能力 SID
          <HOST>\<SandboxUsers>:(OI)(CI)(M)
          BUILTIN\Administrators:(I)(F)          ← 提权时才生效
          NT AUTHORITY\Authenticated Users:(I)(M) ← 当前用户实际拿到的就是这条
          BUILTIN\Users:(I)(RX)
          Mandatory Label\Low Mandatory Level:(OI)(CI)(NW)

隔离实验（同一台机、同一账户、未提权；对象由该账户自己创建）：

目标对象上授予该账户的权限	icacls <file> /setintegritylevel
FullControl	成功（写入 Mandatory Label\Medium Mandatory Level:(NW)）
只授 TakeOwnership（= WRITE_OWNER）	成功
只授 ChangePermissions（= WRITE_DAC）	Access is denied.
只授 ReadPermissions（= READ_CONTROL）	Access is denied.
只授 Modify	Access is denied.

⇒ 这道门是 WRITE_OWNER，与完整性级别、与特权都无关：同一账户 whoami /priv 里没有任何安全相关特权，照样写得进去。这也推翻了我们自己的第一个猜想（「需要提权 / SeSecurityPrivilege」）：.NET Set-Acl 报 SeSecurityPrivilege 是那个 API 的副作用（它把 SACL 一起重写），原生 SetNamedSecurityInfoW / icacls 只要对象上的 WRITE_OWNER。上一版结论之所以在某些运行里成立，是因为提权令牌启用了 BUILTIN\Administrators，而工作区 DACL 里恰有一条 BUILTIN\Administrators:(I)(F)——那次拿到的是 WRITE_OWNER，不是特权。

失败会留下半成品：这次 apply 整体回滚，于是当时 <project-root> 的 DACL 里只剩一条旧版本遗留的能力 ACE（掩码 0x1301FF）、标签完全没有；<workspace-B> 连能力 ACE 都没有。扫描 %TEMP% 下 302 个 dsh-* 临时目录，没有一个带 Low 标签。当天稍晚复核时 <workspace-B> 的能力 ACE 已经是现行掩码 0x110156（说明其间有过一次成功的授权），而 <project-root> 仍是 0x1301FF——同机两个工作区、同一份代码，却停在不同代际的描述符上，正好把这条漂移照出来了。

两个症状的关系：能写标签的那次 provision（提权运行，拿到 Administrators:(F)）把 Low 标签落到目录上，目录里的启动器随之继承 → 弹窗；此后非提权的每次 provision 都在 WRITE_OWNER 上失败 → 授权看起来「不生效」。而由于磁盘上那条能力 ACE 的掩码是旧值 0x1301FF（当前代码的 GRANT_MASK = 0x110156，少了读／执行位），hasExactGrant 永不命中，于是每次 provision 都要走完整 apply、每次都要 WRITE_OWNER——跳过路径本可以完全避开这次写。

边界（按设计，非本次提权引入）：受限的是写，不是读／网络；受限子进程（WRITE_RESTRICTED + LUA_TOKEN + DISABLE_MAX_PRIVILEGE，可见特权只剩 1 个）在 <project-root> 内可写，而 <workspace-B>、C:\Users\Public、C:\Windows\Temp、桌面一律 Win32 5。工作区被标 Low 之后，同用户其它低完整性进程（例如浏览器保护模式）也能写工作区——这是 Low 方案本身的设计代价。

---

English summary

Symptom. After updating to 0.1.7, double-clicking a project's own launchers inside a workspace (.bat/.cmd/.exe) shows the shell's Open File - Security Warning ("the publisher could not be verified") every time.

Cause. d5ad3baeb5 (2026-09-19) makes every write grant stamp the granted root with an inheritable Low integrity label (S-1-16-4096, SYSTEM_MANDATORY_LABEL_NO_WRITE_UP, OI|CI). Every child of that root — the launchers included — therefore materializes Low, and the shell interposes its publisher confirmation before launching a Low-integrity executable. It is not Mark of the Web (a full Zone.Identifier scan is empty), nor file content/encoding/signature. A workspace granted before the update keeps the old descriptor shape and does not prompt at all.

Fix proposed (commit f6698853f3). At the end of every grant — the full apply and the exact-ACE skip, since the skip is what a standing workspace grant takes on every provision — re-assert an explicit informational Medium label (S-1-16-8192, SYSTEM_MANDATORY_LABEL_NO_POLICY, no inheritance) on the granted root's top-level .bat/.cmd/.exe. Policy 0 keeps the confined child's write authority exactly as the capability DACL grants it; the directory label, the world delete deny and the capability ACE stay untouched, and an already-explicit caller label is left alone. Covered by tests/root-launcher-exemption.spec.ts; the package suite (169 tests), typecheck, lint, doc gates and a full build pass. Note the Medium RID is 0x2000 (S-1-16-8192); S-1-16-16384 is System. Writing a label needs WRITE_OWNER on the object (isolated below), which is why the pass belongs inside the grant path: the grant's own success proves the caller holds it, and that ACE is what inherits to the launchers.

Second, related defect — the same WRITE_OWNER gate. A workspace-write grant did not take effect: writes inside the workspace were denied, and because the sandbox is fail-closed the command was rejected before it ran, so it presents as "the option I picked does nothing / the sandbox account has no rights here". Reproduced with the module itself: grantWrite(<project-root>) → SetNamedSecurityInfoW failed (Win32 5). Root cause: no ACE on the workspace root names the user at all — their access comes from the inherited NT AUTHORITY\Authenticated Users:(OI)(CI)(M), i.e. Modify with no WRITE_OWNER, and ownership does not supply it (owner-implicit rights are READ_CONTROL + WRITE_DAC). The merged apply writes the DACL and the SACL label, and the label step needs WRITE_OWNER, so the whole call fails with Win32 5 and fail-closed turns "could not stamp the label" into "this workspace is unusable". The module README already flags a Modify-only directory as a loud failure — this is exactly that case, and it is the ordinary shape of a folder on a data drive. Isolation, same machine/account, unprivileged, on files the account owns: FullControl → label written; TakeOwnership only → label written; ChangePermissions only, ReadPermissions only, Modify only → Access is denied. So the gate is WRITE_OWNER and nothing else: the same account's whoami /priv lists no security privileges at all, which also retires our own first hypothesis (elevation / SeSecurityPrivilege). .NET Set-Acl's SeSecurityPrivilege error is an artefact of that API rewriting the SACL; native SetNamedSecurityInfoW/icacls only needs WRITE_OWNER. Elevation appeared to fix it because an elevated token carries BUILTIN\Administrators, and that workspace's DACL has BUILTIN\Administrators:(F) — WRITE_OWNER, not a privilege. The failed apply is atomic and rolled back, leaving a half-state: <project-root> kept only a stale capability ACE (0x1301FF against the current GRANT_MASK = 0x110156, i.e. the old mask still carries read/execute) and no label at all, <workspace-B> had neither, and none of the 302 %TEMP%\dsh-* directories carried a Low label. A later check the same day found <workspace-B> already holding a current-mask ACE — some run did provision successfully — while <project-root> still held 0x1301FF: two workspaces, one machine, one build, on different descriptor generations. And because that stale mask makes hasExactGrant never match, every provision re-applies the descriptor and therefore demands WRITE_OWNER every single time — the skip path would have avoided the write entirely. Provisioning-only again: the confined child (WRITE_RESTRICTED + LUA_TOKEN + DISABLE_MAX_PRIVILEGE) still cannot write <workspace-B>, C:\Users\Public, C:\Windows\Temp or the desktop.

Known edges of the patch. revokeWrite clears the directory label only, so a file-level Medium label outlives the grant (deliberate — it is indistinguishable from a caller's own icacls label, and the keep verdict exists to protect that). A launcher created mid-session stays Low until the next grant. Only the root's top level is scanned. And since the exemption writes a file label, it needs WRITE_OWNER on each launcher too: a workspace whose DACL grants the caller only Modify fails the grant itself, so the exemption cannot run either — the README bullet about WRITE_OWNER arguably needs to cover the launcher files, not just the directory.

[ZYFDroid]

影响不止如此，用Visual Studio打开项目后尝试构建还会出现MSBuild拒绝构建从互联网上下载的不安全的源码的报错，需要清理掉才可以正常构建

[argszero]

A short pointer from the provisioning side of this report, because its second section (the WRITE_OWNER gate) is the same failure as #7750 and now has a stopgap:

@argszero/cordis-plugin-sandbox-grant-advisor@0.4.0 recognizes the exact line your probe produced (grantWrite(<dir>) → SetNamedSecurityInfoW failed (Win32 5)) on the public tools/post-execute seam and attaches one durable advisory per agent, naming the missing right, recommending the narrow icacls "<dir>" /grant "<user>:(OI)(CI)(WO)" — the right the backend's prerequisite actually names, rather than Full control — and stating the version boundary (0.1.7-alpha.1 introduced the merged DACL + label write; up to 0.1.6-alpha.x the same string has a different cause space). It repairs nothing: no ACL is written, nothing is elevated.

Your isolation table settles the gate, and I have folded it into that plugin's README as the independent confirmation — FullControl or TakeOwnership alone writes the label, ChangePermissions / ReadPermissions / Modify alone do not. The companion note on the mechanism, the flag values and the source anchors is in #7750.

What the plugin deliberately does not attempt is this report's headline half: the publisher-confirmation dialog for an inherited-Low .bat/.cmd/.exe never reaches a tool result, so nothing at that seam can classify it — your patch proposal and its known edges stay with the maintainers, and the stale-mask detail (a rolled-back apply leaving 0x1301FF where GRANT_MASK is now 0x110156, so hasExactGrant never matches and the skip path is unreachable) is exactly the kind of fact that argues for the diagnostic living inside grantWrite.