[Bug] workspace-write: 所有 shell 命令因预授权缺 WRITE_OWNER 失败 (SetNamedSecurityInfoW Win32 5)

[IseyMeow]

Windows 非提升标准用户，目录属主为本人，目录 ACL 无 Deny 项、继承的 BUILTIN\Administrators:(F) 因令牌无该组而不生效， 令牌对目录的有效掩码为 Authenticated Users: 0x1301bf。 DSH workspace-write 预授权调用 SetNamedSecurityInfoW 时因缺 WRITE_OWNER 得到 Win32 5， 导致该模式下所有 shell 命令在启动前即失败；danger-full-access 下命令正常。 工作区换成全新目录同样复现；该目录上任一历史沙箱条目（掩码 0x110156）均不含 WRITE_DAC/WRITE_OWNER。
此bug会导致无法在沙箱内执行pwsh命令。
DSH-缺陷反馈-workspace-write预授权Win32-5.md
附件是DSH自己写的反馈

[IseyMeow]

补充取证报告-E盘权限与重启复测.md
作补充（这个也是DSH自己写的）

[PerryLink]

你的取证很干净（WRITE_DAC=True WRITE_OWNER=False / VERDICT=PRECONDITION 与脚本机制完全对应），报错也在源码里逐字可查。但有三处事实要更正，其中两处会直接影响你能不能今天就修好。

1. 真根因可以精确到行（不必猜）

你附件里猜了两种可能（带 OWNER_SECURITY_INFORMATION / 带 SACL_SECURITY_INFORMATION）—— 都不是。实际是一次调用同时写 DACL 与 LABEL：

packages/sandbox/sandbox-windows-acl/src/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,
)

:262 抛错 → throwWin32(api, 'SetNamedSecurityInfoW', applyResult, `${label}(${path})`)，label 由 grantWrite 传入 ⇒ 与你贴的 SetNamedSecurityInfoW failed (Win32 5): grantWrite(<路径>) 逐字吻合。错误文案格式在 packages/subprocess/win32-process/src/errors.ts:9。

为什么 DACL 改得动、调用却 Win32 5：LABEL 在 SACL 里，而写 SACL 需要 WRITE_OWNER；属主隐式权限只覆盖 READ_CONTROL + WRITE_DAC。这一条在仓库里有两处明文：

• README.md:130 → 「Granted directories must be caller-owned and grant WRITE_OWNER — the owner's implicit rights cover only READ_CONTROL and WRITE_DAC; the label lives in the SACL, so the combined apply additionally needs WRITE_OWNER (a Full-control directory, the normal workspace case, has it). A directory whose DACL grants only Modify now fails the grant loudly instead of silently skipping the confinement.」
• acl.ts:368-370 同义

⇒ 所以这是设计内的前置条件失败，不是代码缺陷。你那句 Authenticated Users:(M)=0x1301bf 与沙箱的 S-1-4-*:(OI)(CI)(W,D,DC)=0x110156 都不含 WRITE_OWNER（win32-abi.ts:28 的 GRANT_MASK = 0x00110156），与结论一致。

2. ⚠️ 更正一：「沙箱实现打包在 app.asar 内，无法读取」——不成立

@deepseek-ai/dsh-sandbox-windows-acl 是公开 npm 包 + 公开源码仓，src/acl.ts 就在上游仓库里。你其实已经具备定位条件，只是没往公开源码找 —— 这也正是你只能列"可能 A / 可能 B"的原因。这条更正对你有利：它说明你能自己查到根因。

3. ⚠️ 更正二：那个 SID 不是运行时临时身份，可以精确算出

你写"该 SID 在本机不可解析 → 是运行时临时身份、无法预知 → 无法手工预授权"。SID 是确定性派生的：

packages/sandbox/sandbox-windows-acl/src/workspace-sid.ts:35-40：

export function workspaceWriteSid(workspaceRoot: string): string {
  const digest = createHash('sha256').update(workspaceRoot, 'utf8').digest()
  const first = (digest.readUInt32LE(0) % (2 ** 30 - 1)) + 1
  const second = (digest.readUInt32LE(4) % (2 ** 30 - 1)) + 1
  return `S-1-4-${first}-${second}`
}

我按这个函数实算了你那个工作区路径 —— 结果 S-1-4-698055174-229371875，与你附件里那条 ACE 的 SID 一字不差。

S-1-4-*（SECURITY_NT_NON_UNIQUE）解析不出账户名是设计（workspace-sid.ts:8-11：「The SID's power is defined solely by the ACEs that name it … the SID string itself is not a secret」），不是"身份已随旧会话销毁"。

⚠️ 但这不改变结论：即使你手工为那个 SID 预授权，grantWrite 仍然要写 SACL 标签、仍然需要 WRITE_OWNER。所以"手工预授权不可行"是对的，只是理由要换成标签那一步。

4. ⭐ 更正三：「补完整控制权限不对症」——恰恰对症，这是你今天就该跑的一条

这正是内置诊断脚本的既定动作。assets/diagnose-windows-sandbox-acl/scripts/diagnose-windows-sandbox-acl.ps1：

• :640-644 → $grantTargets = @($inspectOrder | Where-Object { … ((-not $factsByPath[$_].HasWriteDac) -or (-not $factsByPath[$_].HasWriteOwner)) … })
• :656-667 → 写入当前用户的 FullControl allow ACE

配套说明：

• README.md:80 → 「adds the signed-in user's full-control allow ACE to chain directories that lack effective WRITE_DAC or WRITE_OWNER」
• SKILL.md:14 → 「because DSH cannot provision its workspace grant without them」

⇒ 脚本自己把 WRITE_OWNER 缺失当作可修目标。FullControl 含 WRITE_OWNER，补上之后 provision 即可通过。

推荐路径（唯一且现成）：跑内置技能 diagnose-windows-sandbox-acl（一次调用、一次审批、带备份与回滚），必须在非受限会话里跑。它会给你工作区根补一条当前用户 FullControl allow ACE。

5. 你附件里的两个「脚本卡点」

• $PSCommandPath 唯一使用点确实在 :363 —— 你的引用正确。
• 「执行策略拒绝脚本文件」不是脚本缺陷：powershell.exe -ExecutionPolicy Bypass -File "<脚本>" 是标准做法。而你 §6 第 4 次失败是 -File 后面把数组路径拼成了单个字符串 —— -File 只接受一个脚本路径，属调用方式问题。
• 完整写法：powershell.exe -ExecutionPolicy Bypass -File "<脚本>" -Path '<工作区>' -AllowRoot '<工作区>' -Out '<可写目录>'。脚本本身 PS 5.1 兼容（只用 ::new()，:288/493-495/663）。

6. 一条值得上游知道的事实（你无意中暴露的）

你附件 §4 自述这台机器没装 pwsh 7 —— 而 @deepseek-ai/dsh-* 目前对 pwsh 7 有硬依赖。这本身是另一条值得提的环境要求问题，建议单独提一句。

7. 建议上游补一条可读失败提示

grantWrite 失败时区分「DACL 被拒」与「LABEL 被拒（缺 WRITE_OWNER）」，并直接指向该诊断技能 —— 现在只抛裸 Win32 5。这是你这篇报告最有价值的产品改进项，建议放在建议的第一条。

8. 版本与临时规避

你没写包版本；相关代码在 origin/master（= dsh-v0.2.1-alpha.2）与 0.2.0-rc.2/0.2.1-alpha.2 的打包产物上逐行一致。临时降级 danger-full-access 可绕过预授权（packages/shell/pwsh-sandbox/src/index.ts:99-104 直接走 super.execute、不做 confine），但会同时关掉沙箱。

9. 一条边界

那台机器上是否还有第二个隐含阻断，我无法核实。不过你附件 2.2 已给出 E:\ 的用户权限形态，与结论一致，不构成反例。

[IseyMeow]

感谢！虽然没太看懂但是丢给DSH后他给我写了个执行脚本，可以单次修复工作区（及其内的文件夹）的相关问题，暂时不动其他的了