[sandbox-windows-acl] 标准用户 + 非系统盘工作区下 workspace-write 完全不可用：缺少 WRITE_OWNER 导致 grantWrite 失败

[Kanade-Tachibana2525]

说明：本仓库关闭了 Issues（has_issues = false），按 README 指引发到 Discussions / General。正文保留了 bug 报告的结构（复现 → 根因 → 证据 → 影响 → 建议）。

Environment / 环境

项	值
DSH	0.1.7-rc.2
OS	Windows 11 23H2 (build 22631.4460, AMD64) （注册表 ProductName 显示 "Windows 10 Pro"，是微软已知的 Win11 遗留值）
账户	标准用户（非管理员），IsInRole(Administrator) == false
工作区	D:\dsh（非系统盘）
文件策略	workspace-write
相关包	@deepseek-ai/dsh-sandbox-windows-acl@0.1.7-rc.2

English summary

On a standard (non-admin) Windows account, if the workspace directory's DACL grants only Modify (the common case for directories on non-system drives, inherited as Authenticated Users: Modify), the workspace-write backend cannot materialize its grant and every confined shell call fails — including a command that writes nothing:

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\dsh)

The prerequisite is documented in sandbox-windows-acl's "Verified boundaries", but not in any user-facing README (dsh-sandbox, dsh-pwsh-sandbox, dsh-base, dsh-sandbox-policy), and the error carries no actionable guidance. The result is that users must approve danger-full-access for every command, which defeats the purpose of workspace-write.

摘要

在标准用户账户下，若工作区所在目录的 DACL 只授予 Modify，workspace-write 沙箱无法完成授权物化，每一条受限 shell 命令都会失败——包括 pwd 这种不写任何东西的命令：

SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\dsh)

用户看到的现象是：所有命令都必须请求「完整权限」才能执行，等于 workspace-write 在该工作区完全不可用。

前提已记录在 packages/sandbox/sandbox-windows-acl/README.md 的 "Verified boundaries" 一节，但面向用户的文档均未提及，且报错未给出可操作指引。

最小复现

以标准用户身份，在一个 DACL 只授予 Modify 的目录上（例如非系统盘根目录下新建的子目录）：

# 1) 目录权限：所有者是自己，但没有针对自己的显式 ACE
$dir = 'D:\repro-ws'
New-Item -ItemType Directory -Path $dir | Out-Null

(Get-Acl $dir).Owner
#   => <machine>\<user>            (自己就是所有者)

(Get-Acl $dir).Access | Where-Object { $_.IdentityReference -like "*$env:USERNAME*" }
#   => 空                          (没有任何针对自己的 ACE)

icacls $dir
#   => NT AUTHORITY\Authenticated Users:(I)(M)
#      BUILTIN\Users:(I)(RX)  ...  (只继承了 Modify)

# 2) 标签写入失败 —— 这正是 grantWrite 内部的那一步
icacls $dir /setintegritylevel "(OI)(CI)Low"
# D:\repro-ws: Access is denied.
# exit code 5

# 3) 补一条显式的 WRITE_OWNER（TakeOwnership）
$me = "$env:USERDOMAIN\$env:USERNAME"
$acl = Get-Acl $dir
$acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule(
  $me, 'TakeOwnership', 'ContainerInherit,ObjectInherit', 'None', 'Allow')))
Set-Acl -Path $dir -AclObject $acl

# 4) 同一操作现在成功
icacls $dir /setintegritylevel "(OI)(CI)Low"
# Successfully processed 1 files; Failed processing 0 files.
# exit code 0

对照组：对 %TEMP% 下新建的目录（用户有继承来的 FullControl）执行第 2 步，直接成功，无需任何改动。

根因

packages/sandbox/sandbox-windows-acl/src/acl.ts 的 mergeAndApply 用一次 SetNamedSecurityInfoW 同时应用 DACL 与完整性标签（编译产物 lib/types-*.js）：

const applyResult = api.setNamedSecurityInfoW(
  path, 1,
  labelEdit.kind === "keep" ? 4 : 20,   // 4 = DACL_SECURITY_INFORMATION
                                        // 20 = DACL(0x4) | LABEL(0x10)
  null, null,
  newAcl,
  labelEdit.kind === "apply" ? labelEdit.acl : null);

链条如下：

1. 完整性标签存放在 SACL；写入它需要对象的 WRITE_OWNER。
2. 对象所有者隐式获得的只有 READ_CONTROL + WRITE_DAC —— 不含 WRITE_OWNER（这一点 sandbox-windows-acl 自己的 README L122 已写明）。
3. Modify 的访问掩码是 0x1301bf，不含 WRITE_OWNER 位 0x00080000。
4. 因此：DACL 那部分本可成功（owner 隐式 WRITE_DAC），但标签那部分失败 → 整个调用返回 ERROR_ACCESS_DENIED (5)。

这与 README.md L122 / README.zh.md L122 记录的边界一致：

被授权目录必须由调用者拥有并授予 WRITE_OWNER。 所有者隐式获得的只有 READ_CONTROL 与 WRITE_DAC；标签位于 SACL，因此合并应用还需要 WRITE_OWNER（完全控制目录——即正常工作区情形——本就具备）。DACL 只授予 Modify 的目录现在会大声失败，而不是静默跳过隔离。

即：该边界是已知且刻意的，fail-closed 本身正确。问题在于触发条件在真实环境里很常见，而用户完全拿不到解释。

为什么后端无法自行解决

这是权限自举问题：要在目录上获得 WRITE_OWNER，本身就需要该目录的 WRITE_OWNER，或管理员特权（如 SeTakeOwnershipPrivilege）。标准用户在这类目录上两者都没有。

本帖不主张改成静默跳过隔离——无法强制执行时失败是正确的取舍。

实测证据

1. 真实会话：策略 workspace-write 下，一条只有 pwd 的命令失败：
   SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\dsh)

2. 受控 A/B：上述最小复现。同一个继承而来的 ACL，补 WRITE_OWNER 前 exit 5、补后 exit 0。

3. 端到端（走公开 API）：补齐后直接调用 AclSandbox：

   const sandbox = new AclSandbox({
     writableDirs: [ws],
     tempDir: null,
     writeSid: workspaceWriteSid(ws),
     mode: 'workspace-write',
   });
   await sandbox.init();          // OK（修复前此处抛 Win32 5）

   随后 spawn 受限子进程：

   目标	结果
   写工作区内	exit=0，文件创建成功
   写工作区外	exit=3，EPERM，文件未创建

   说明隔离本身工作正常，卡住的只有「授权物化」这一步。

4. 继承行为（有用的 workaround）：给 D:\dsh 补上可继承的 (OI)(CI)(M,WO) 后，其新建子目录自动继承该 ACE，可直接作为工作区使用，同样通过第 3 项的端到端验证。

影响

• 触发面比文档假设的宽。 文档称「完全控制目录——即正常工作区情形——本就具备」，但用户很自然会选非系统盘、移动硬盘、其他分区的工作区；这些目录常由盘根以 Authenticated Users: Modify 继承而来，标准用户拿不到 WRITE_OWNER。
• 后果是整个工作区不可用，而非部分功能降级。失败发生在每一条命令上（连只读命令也失败，因为授权在进程 spawn 前物化），用户只能不断批准「完整权限」才能干活——等于必须关掉沙箱，与 workspace-write 的设计意图正好相反。
• 报错不可操作：只给出 Win32 5，与真实原因（缺少 WRITE_OWNER）之间没有任何提示。

建议

1. 让报错可操作（最小改动，收益最大）

在 grantWrite 失败且错误为 ERROR_ACCESS_DENIED 时，说明原因并给出一次性修复命令，例如：

SANDBOX_UNAVAILABLE: 工作区 "D:\dsh" 未向当前用户授予 WRITE_OWNER。
Windows ACL 后端需要它以写入完整性标签（标签位于 SACL）。
该权限无法由 DSH 自行取得；请以你的账户执行一次：

  $acl = Get-Acl 'D:\dsh'
  $acl.AddAccessRule((New-Object System.Security.AccessControl.FileSystemAccessRule(
    "$env:USERDOMAIN\$env:USERNAME",'TakeOwnership','ContainerInherit,ObjectInherit','None','Allow')))
  Set-Acl -Path 'D:\dsh' -AclObject $acl

2. 选定工作区时预检

在物化授权前检查（owner 是否为当前用户、是否存在有效的 WRITE_OWNER），在用户选择工作区时就告警，而不是等到第一条命令失败、且只报一个 Win32 码。

3. 补文档

把该前提写进用户可见的文档（dsh-sandbox / dsh-pwsh-sandbox / dsh-base / dsh-sandbox-policy 的 README），而不只是后端包 README 的 "Verified boundaries"。

4. 可选的自愈（须用户显式确认）

调用者已是所有者（隐式 WRITE_DAC），因此有能力改写自己的 DACL——而后端本来就在做 DACL 变更（能力 ACE + FILE_DELETE_CHILD 拒绝项）。可在首次遇到该错误时询问用户是否允许为 owner 补一条 WRITE_OWNER。

注意这会改变目录的安全语义（允许该用户取得所有权），因此应当显式选择加入，不适合默认静默执行。

附：相关文件位置

位置	内容
packages/sandbox/sandbox-windows-acl/src/acl.ts	mergeAndApply：合并 DACL + 标签的单次 SetNamedSecurityInfoW
packages/sandbox/sandbox-windows-acl/README.md L122 .../README.zh.md L122	已记录的边界：目录须由调用者拥有并授予 WRITE_OWNER
packages/sandbox/sandbox/README.md L12	fail-closed 原则：无法强制执行时以 SANDBOX_UNAVAILABLE 失败，绝不不受限运行

[argszero]

The signature is already watched by a shipped advisory, and the documentation gap you found is real.

Your message matches verbatim the signature a plugin I maintain classifies — SetNamedSecurityInfoW failed (Win32 5): grantWrite(D:\ws) — so the diagnosis and the remedy path are delivered in-band today, without waiting for a docs change:

• @argszero/cordis-plugin-sandbox-grant-advisor — mount it in the profile and it attaches one user-role advisory per agent to the failing tool result, so the user sees the cause and the command rather than a bare Win32 5.

What the advisory says, and how it lines up with your report:

• The missing right is WRITE_OWNER — an object right the caller can self-grant — which is why SeSecurityPrivilege and elevation are not the prerequisite. Your step 3 (adding an explicit WRITE_OWNER) is the same conclusion reached from the other end.
• The remedy forks on an ownership check the user runs — (Get-Acl "<dir>").Owner — because one command cannot serve both rights situations: where the caller owns the directory, the unelevated icacls "<dir>" /grant "<account>:(OI)(CI)(WO)" is the whole of what is missing (the owner's implicit WRITE_DAC already covers the DACL half); where the caller does not own it, that same command is refused for want of WRITE_DAC and the grant has to come from an elevated account, or by taking ownership first, or by moving the workspace under %USERPROFILE%. Your standard-account non-system-drive case is the second branch.
• The version boundary: the mandatory-label write arrives with 0.1.7-alpha.1 (flag 20), versus the DACL-only flag 4 up to 0.1.6-alpha.x, together with why downgrading is not the remedy.
• The two remedies that look right and are not — takeown and icacls /reset — each with the reason it fails.
• The scope: the grant covers the directory it names and its children, so a sibling workspace root on the same volume needs the line once more.
• Version note for your environment: the repository's own diagnose-windows-sandbox-acl skill is not part of the 0.1.7 line at all — it arrives with 0.2.0 (measured on both published tarballs: 0.1.7-rc.2 names it zero times, ships no assets and carries no registration symbol anywhere in its tree, while 0.2.0-rc.2 ships assets/diagnose-windows-sandbox-acl/ and names it per README). A reader on 0.1.7-rc.2 who saw the promise in a README was reading a 0.2.0-era document.

On the documentation half: your claim checks out. git grep WRITE_OWNER on origin/master hits exactly two files tree-wide, both packages/sandbox/sandbox-windows-acl/README*; nothing under docs/, and no user-facing README (dsh-sandbox, dsh-pwsh-sandbox, dsh-base, dsh-sandbox-policy) states the prerequisite. That is a real gap this plugin works around at runtime rather than fixes, and it deserves its own report if it does not have one.

0.12.0 was published today; the ACL family's diagnosis is unchanged in it apart from wording shared across the families. The plugin is diagnosis and optional repeat-detection only — it never edits an ACL, never elevates, never changes a preset or a mode.