[Bug] Windows 非系统盘工作区在 workspace-write 下全部命令不可用：grantWrite 需要 WRITE_OWNER，而工作区目录默认没有

[FalseLeonLai]

摘要

在非系统盘用资源管理器新建一个普通文件夹作为工作区，切到 workspace-write 后任何命令都无法执行（含 Get-Location 这类纯只读命令），报错发生在命令执行之前：

Error: SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\project\AI\DSH4)

read/write/edit 工具不受影响；切到 danger-full-access 一切正常；稳定复现。

严重级别：高——该模式在该类工作区下 100% 不可用。触发条件只是"在非系统盘建一个文件夹"，属最主流用法。

环境

项	值
DSH	profile desktop，@deepseek-ai/dsh-sandbox-windows-acl 0.1.7-alpha.2
系统	Windows，NTFS 卷 D:（非系统盘，Healthy），无 EFS 加密
用户	非提升态（Medium 完整性，Administrators = group used for deny only）
工作区	D:\project\AI\DSH4（资源管理器新建的空目录）
预设	workspace-write（sandbox=workspace-write, approval=ask）

最小复现

1. 在非系统盘用资源管理器新建一个空文件夹；
2. 新建会话，工作目录指向它，权限预设设为 workspace-write；
3. 执行任意命令（Get-Location 即可）→ 报上述错误；
4. 对照组：改 danger-full-access → 正常；把工作区移到 %USERPROFILE% 下 → workspace-write 也正常。

第 4 步把变量锁死在「目录 ACL 继承」这一个因素上。

根因

packages/sandbox/sandbox-windows-acl/src/acl.ts 的 grantWrite 对工作区目录做一次 SetNamedSecurityInfoW 调用，同时写入三样东西：

1. 能力 SID 的允许 ACE；
2. world SID 的 FILE_DELETE_CHILD 拒绝 ACE；
3. Low 强制完整性标签（位于 SACL）。

// acl.ts:255-259
const applyResult = api.setNamedSecurityInfoW(
  path, abi.SE_FILE_OBJECT,
  labelEdit.kind === 'keep'
    ? abi.DACL_SECURITY_INFORMATION
    : abi.DACL_SECURITY_INFORMATION | abi.LABEL_SECURITY_INFORMATION,  // ← 关键
  null, null, newAcl, labelEdit.kind === 'apply' ? labelEdit.acl : null,
)

写 SACL 中的完整性标签需要对象上的 WRITE_OWNER，仅 WRITE_DAC 不够。该包源码 acl.ts:368-370 已声明这个前提：

The directory must be owned by the caller AND grant WRITE_OWNER (the label lives in the SACL; owner-implicit rights cover only READ_CONTROL and WRITE_DAC) — a Full-control workspace satisfies both.

但盘符根目录的默认 ACL 不满足。本机 D:\ 的继承权限：

NT AUTHORITY\Authenticated Users    Modify, Synchronize   (I)(OI)(CI)   ← Modify 掩码不含 WRITE_OWNER (0x00080000)
BUILTIN\Users                       ReadAndExecute        (I)(OI)(CI)
NT AUTHORITY\SYSTEM                 FullControl
BUILTIN\Administrators              FullControl           ← 未提升时为 deny only，访问检查中被忽略

检查项	实际	结论
调用者是所有者	是	满足
所有者隐式权限	仅 READ_CONTROL + WRITE_DAC	不含 WRITE_OWNER
DACL 是否授予 WRITE_OWNER	继承的 Authenticated Users:(M) 不含	不满足
特权兜底	UAC 未提升 → SeTakeOwnership 被剥离	无

→ ERROR_ACCESS_DENIED (5)。可写 DACL，不可写 SACL。

诊断证据（对照组实验）

测试	结果	推论
目录内创建 / 删除文件	成功	文件系统写权限正常，问题不在写文件
Set-Acl 添加允许规则	成功	DACL 可写，排除「ACL 完全不可改」
icacls /grant ...:(OI)(CI)M	成功（退出码 0）	同上；证明与沙箱走同一个 Win32 API
目录外写入（%USERPROFILE%）	被拒绝	证明沙箱确在生效，排除"停在完全访问模式"的假阳性
cipher 加密属性	U（未加密）	排除 EFS 干扰

决定性对比——同一进程、同一用户，仅目录位置不同：

目录	权限来源	结果
%LOCALAPPDATA%\Temp\dsh-XXXX\（沙箱私有临时目录）	继承自用户目录 → 用户 FullControl	授权正常
D:\project\AI\DSH4（工作区目录）	继承自 D:\ → Authenticated Users:(M)	Win32 5

同一份代码、同一个用户，差别只在目录位置带来的 ACL 继承差异。

补充发现：这个失败无法被前置发现

看起来探测本该拦住它，但 Windows 上两层都失效。

packages/sandbox/sandbox-local/src/index.ts 的探测函数：

function defaultProbeWindowsAcl(runnerInvocation: string[], timeoutMs: number): boolean {
  const probe = spawnSync(program, [
    ...runnerInvocation.slice(1),
    '--workspace', tmpdir(), '--temp', tmpdir(), '--mode', 'read-only',   // ← 只读模式
    '--', 'cmd', '/c', 'exit', '0',
  ], { timeout: timeoutMs, stdio: 'ignore' })
  return probe.status === 0
}

它自己的注释写着："run the runner in read-only mode (zero grants, no ACL mutation)"——即探测根本不走出问题的授权路径。

同时该文件的注释又写着："The win32 chain is a sole candidate, so the product never probes"，而 PLATFORM_CHAINS.win32 = ['windows-acl']，chainVerdict() 对单候选直接返回 { runner: 'windows-acl', enforcement: 'partial' }。

结果：链路被判定为健康，授权在第一条 workspace-write 命令时才在 sandbox-local 的 materializeAclGrant 里懒物化并失败。用户拿到的是原始 Win32 错误，而不是 SandboxUnavailableError——与沙箱「拒绝 / 不可用」的语义区分相反。

缺陷清单

1. grantWrite 的 WRITE_OWNER 前提只写在注释里，从不校验。sandbox-windows-acl/src/index.ts 的构造函数仅校验存在性与目录类型：

   if (!existsSync(absolute) || !statSync(absolute).isDirectory()) {
     throw new Error(`AclSandbox writable dir does not exist or is not a directory: ${absolute}`)
   }

2. 链路健康探测不覆盖授权路径：Windows 探测跑 --mode read-only（零授权），且 win32 单候选链根本不探测。授权失败无法被前置发现。
3. 失败不降级：add() 抛错 → 实例被 dispose（撤销全部可撤销授权）→ 模式整体不可用，无「警告后按较低保证运行」路径。
4. 前提在错误的层被假定：「工作区有 FullControl」在 %USERPROFILE% 下成立，但工作区是任意路径，跨盘符时假定失效，而没有任何一层去建立它。

建议修复

1. Provision 阶段补齐权限（首选）：检测工作区是否具备 WRITE_OWNER，缺失则为当前用户补一条可继承的 FullControl ACE——该包本就具备修改 DACL 的能力。
2. 让探测覆盖授权路径：Windows 探测在 workspace-write 下对真实工作区做一次真实授权，或直接校验 WRITE_OWNER，失败即判 unusable，抛出 SandboxUnavailableError 而不是把原始 Win32 错误漏给用户。
3. 可操作的报错：缺失时抛出带修复命令的错误，例如
   workspace-write 需要 <path> 授予 WRITE_OWNER：icacls "<path>" /grant "%USERNAME%:(OI)(CI)F"
4. 文档补充：包 README 明确要求工作区目录具备 FullControl，并说明非系统盘的默认继承不满足该前提。

本机临时绕过（已验证）

icacls '<工作区路径>' /grant "${env:USERNAME}:(OI)(CI)F"

注意 (M)（Modify）无效——Modify 掩码不含 WRITE_OWNER，必须用 (F)。

验证方式：修复后工作区内写入成功 且 工作区外写入被拒绝，两者同时成立才证明是 workspace-write 模式在生效（否则可能只是停在 danger-full-access）。

未验证的推断

以下为推断，未实测：

1. 修复生效是因为幂等检查 hasExactGrant && hasExactDeny && hasExactLabel 未命中而重新 apply，而非存在「仅改 DACL」的降级路径。依据：源码只有一条 grantWrite 路径。
2. 任何「根目录 ACL 只给 Modify、用户未提升」的盘符都会触发——本次只在 D: 上实测。
3. DSH 进程若以管理员提权运行，该问题会因 Administrators:(F) 生效而消失。

附注

Discussion #1312 的附件中也报告过 pwsh/sandbox 问题，但该帖的两条评论均只处理「子代理选模型」一项，并注明 pwsh/sandbox 不在其覆盖范围。因附件内容无法检索，无法确认是否与本问题细节一致，故单开此帖。