工作区目录缺少 WRITE_OWNER 时，grantWrite 报 Win32 5 且错误信息未指明原因

[lincolnwang1]

##背景

在 Windows 上用 DSH 时遇到工作区无法打开的问题，排查后定位到 grantWrite
的授权前置条件不满足。错误信息只给出了 Win32 5,没有指出真正缺的是什么,
花了较多时间才定位,想反馈一下,并提两个改进建议。

环境

• DSH 0.2.0-rc.2(npm 安装)
• Windows 25H2(26200.9457),Professional Workstation
• 当前用户是 BUILTIN\Administrators 成员,但 DSH 非提权运行,
  因此该组在访问令牌中是 deny-only 状态
• 工作区路径:C:\02_project\99_temp,直接位于盘根下的自建目录

现象

打开工作区时直接失败,报:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(C:\02_project\99_temp)

整个会话无法启动,需要手动改目录权限后才能继续。

根因

grantWrite 通过一次 SetNamedSecurityInfoW 调用完成三件事:

1. 给能力 SID 加写权限项
2. 给 Everyone 加一条 FILE_DELETE_CHILD 拒绝项
3. 把该目录的强制完整性标签设为 Low

传入的信息类别是 20(= DACL_SECURITY_INFORMATION 0x4 |
LABEL_SECURITY_INFORMATION 0x10)。其中第 3 项写的是 SACL,而写 SACL
需要 WRITE_OWNER。

问题在于 Windows 给目录所有者的隐式权限只有 READ_CONTROL 和 WRITE_DAC,
并不包含 WRITE_OWNER。而盘根下发的继承权限项里,唯一包含WRITE_OWNER 的是 BUILTIN\Administrators 的完全控制——非提权时它不生效。

最终有效权限是 writeDac=true / writeOwner=false,调用被拒绝。

值得注意的是,这个前置条件在 dsh-sandbox-windows-acl 自己的文档里
已经写明了:

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.

也就是说这是一个已知的、文档化的前置条件,但运行时只抛出了裸的
Win32 错误码。

触发条件

同时满足以下三条即会复现:

1. DSH 非提权运行
2. 工作区目录是自建的,且不在用户 profile 目录下
3. 该目录的 DACL 中没有任何显式授予调用者 WRITE_OWNER 的权限项

对照:用户目录(如 C:\Users\<name>)有一条显式的 user: Full control,
所以 profile 目录下的工作区不会触发。

验证数据

• 修复前:writeDac=true / writeOwner=false
• 给目录加一条显式的 user: Full control 后:两者均为 true,授权成功
• 扫描了 C:\02_project 下 36 个目录,只有 3 个带显式完全控制,
  其中 2 个是之前遇到同样问题后手工修过的——说明复发条件很容易被满足## 已采取的处置

在 C:\02_project 这一处加了 user: Full control 并设为向下继承,
36 个现有子目录和以后新建的子目录全部覆盖,问题不再复发。

(或临时方案:以管理员身份启动 DSH。可用但不推荐,等于整个 agent 都提权。)

两个改进建议

1. 让 grantWrite 的错误信息带上诊断(成本低)

在 SetNamedSecurityInfoW 返回 ACCESS_DENIED 时,把已知的前置条件
一起带进错误上下文,例如:

workspace root C:\02_project\99_temp lacks "allow to change owner"
(WRITE_OWNER); grant it explicitly, or run DSH elevated

2. 在 grantWrite 之前加一次前置检查(能根治复发)

授权前检查目标目录是否具备 WRITE_OWNER,不具备就直接报上面那条可执行的
提示,而不是先失败再让用户去猜 Win32 5 的含义。

考虑到触发条件是确定性的(新建目录 + 非提权),这个检查能省掉一整轮排查。

一个可复用的检测方法

判断某个目录是否满足 DSH 授权的前置条件:

$uid = ([System.Security.Principal.WindowsIdentity]::GetCurrent()).User.Value
$acl = Get-Acl -LiteralPath "C:\02_project\99_temp"
$hit = $acl.Access | Where-Object {
    $_.AccessControlType -eq 'Allow' -and
    ($_.IdentityReference.Value -match "$uid|$([Environment]::UserName)") -and
    $_.FileSystemRights -match 'FullControl|ChangePermissions|TakeOwnership'
}
if ($hit) { "OK" } else { "缺 WRITE_OWNER,DSH 授权会失败" }

如果这个检测逻辑值得沉淀进 dsh-sandbox-windows-acl,让故障能自诊断,
那我这边很愿意把它整理成 PR——虽然目前看 CONTRIBUTING 说明暂不接受外部 PR,
那就先放在这里供团队取用。