[Windows] workspace-write 沙箱下 tempfile.TemporaryDirectory() 失败：chmod 重写 DACL 抹掉 capability ACE

[rabbit0716]

Summary

（背景：我在一个 Python 测试套件里遇到这 37 个失败，定位过程中做的 mode 对照实验如下。）

在 Windows 的 workspace-write 沙箱下（@deepseek-ai/dsh-sandbox-windows-acl 后端），受限子进程无法使用 Python 标准库的 tempfile.TemporaryDirectory() / tempfile.mkdtemp()，持续抛 PermissionError: [WinError 5]。

目录创建和写入本身都成功，失败发生在退出清理时扫描该目录。

触发点是 tempfile.mkdtemp() 的 mode=0o700：沙箱给受限进程新建对象补的 capability ACE，被 chmod 重写 DACL 时抹掉，导致包括创建者在内的所有 restricting SID 都被 write pass-2 检查拒绝。

影响面：任何在 workspace-write 下用标准库 tempfile 的 Python 代码。实测一个 266 用例的测试套件中 37 个受影响（约 14%）。属于静默失败——目录创建和写入都正常，只有清理阶段报错，容易被误判为被测代码的缺陷。

Reproduction

在 workspace-write 受限会话中运行：

import tempfile, os
with tempfile.TemporaryDirectory() as t:      # 退出时报 PermissionError
    open(os.path.join(t, "f.txt"), "w").write("x")   # 这一步成功

更小的隔离复现——同一受限进程内逐个 mode 测试：

import os
base = "D:/some/writable/dir"
os.makedirs(base, exist_ok=True)
for mode in [0o777, 0o755, 0o750, 0o711, 0o700]:
    p = os.path.join(base, f"d{oct(mode)[2:]}")
    os.mkdir(p, mode)
    try:
        open(os.path.join(p, "f"), "w").write("x")
        print(f"{oct(mode)} OK")
    except Exception as e:
        print(f"{oct(mode)} {type(e).__name__}")

Current behavior

0o700 是唯一触发值：

mode	结果
0o777	OK
0o755	OK
0o750	OK
0o711	OK
0o700	PermissionError: [WinError 5]
0o500	OK

完整报错：

PermissionError: [WinError 5] 拒绝访问。:
  'C:\\Users\\<user>\\AppData\\Local\\Temp\\dsh-<hash>\\tmpXXXXXXXX'

栈落在 tempfile.py → shutil.rmtree → os.scandir → _resetperms → os.chmod。即扫描阶段先被拒，清理的重试路径再次被拒。

以下规避手段已实测全部无效：

• 重定向 TMP / TEMP / TMPDIR 到工作区或会话私有临时目录；
• 改用 tempfile.mkdtemp(dir=<可写目录>)。

说明问题不在路径，而在新建目录的 DACL。

补充观测：对失败目录执行 os.stat 报 mode 为 0o777（Windows 上 mode 位不反映真实 DACL），所以不能靠 mode 位判断。

Expected behavior

受限进程对自己创建的目录执行 chmod 后，应当仍可访问该目录；或至少该目录应保留 token default DACL 中的 capability ACE。

Environment

• DSH 0.1.6-alpha.1，commit 0d1f50007f
• Windows 11
• 权限预设 workspace-write（沙箱模式 workspace-write，审批 ask）
• 后端 @deepseek-ai/dsh-sandbox-windows-acl
• Python 3.12.13（受限 pwsh 子进程内）

机制推测（未经直接验证，供定位参考）

packages/sandbox/sandbox-windows-acl/src/index.ts 第 284–296 行的注释说明：受限 token 的 default DACL 只含用户的环境 SID、不含任何 restricting SID；因此代码显式把某个 capability SID 的 full-access ACE 合并进 default DACL（setTokenDefaultDaclGrant），好让新建对象的 DACL 能通过 write pass-2 检查。

在此之上，CPython 的 os.mkdir(path, mode) 在 Windows 上当 mode != 0o777 时会额外执行一次 chmod 来设置权限位。这一次 chmod 重写了新建目录的 DACL，移除了上面那个 capability ACE，于是所有 restricting SID（含创建者自己）都被 pass-2 拒绝。

这一推断能同时解释：只有 0o700 失败（Python 单独为它走 chmod 路径）、重定向临时目录无效（问题在 DACL 不在路径）、以及 stat 报 0o777。

未验证部分：os.mkdir 的 chmod 行为是从 CPython 设计推断的（其 C 实现无法用 inspect 读源码），未在 DSH 内打断点确认。若上游采纳，建议先复核这一步。

建议方向

在 setTokenDefaultDaclGrant 之后，考虑对受限进程新建对象的 DACL 修改保持宽容；或至少让 chmod 不再整体替换 DACL。具体取舍取决于对 pass-2 收紧程度的期望。

[PerryLink]

这条的机制判断成立 —— 而且你标为「未经直接验证」的那一步，我在同一套环境上测出来了（Windows 11 / Python 3.12.14，用 Get-Acl 读 SDDL）。测完的结论比你的假设更窄，也更硬。

你未验证的那一步：成立，但触发条件是「恰好 0o700」

同一父目录下逐个 mode，看新建目录的 DACL 结构：

os.mkdir(p)                  D:AI(A;OICIID;FR;;;WD)(A;OICIID;FA;;;SY)(A;OICIID;FA;;;BA)(A;OICIID;FA;;;OW)
os.mkdir(p, 0o755)           同上
os.mkdir(p, 0o750)           同上
os.mkdir(p, 0o711)           同上
os.mkdir(p, 0o600)           同上
os.mkdir(p, 0o500)           同上
os.mkdir(p, 0o555)           同上
os.mkdir(p, 0o700)           D:P(A;OICI;FA;;;OW)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)
tempfile.mkdtemp()           同 0o700
os.mkdir(p) 之后再 os.chmod(p, 0o700)   DACL 完全未变（同上第一行）

AI = 自动继承，ID = 该 ACE 本身是继承来的；D:P = 保护，不继承，三条 ACE 全是显式的。

对你表述的两点修正：

1. 不是「mode != 0o777」，而是恰好 0o700。 我测的 0o755 / 0o750 / 0o711 / 0o600 / 0o500 / 0o555 全部保留继承 DACL，只有 0o700 走了替换路径 —— 这正好解释你 mode 对照表里为什么只有 0o700 失败，而不只是「Python 单独为它走 chmod」。
2. 也不是「chmod 会重写 DACL」这个一般说法：先 os.mkdir(p) 再单独 os.chmod(p, 0o700)，DACL 一动不动。替换发生在 mkdir 带 0o700 的那条路径里，不是 chmod 本身。

更关键：它不是「照抄父目录」，是换成一个固定集合

我给父目录加一条可继承的 Everyone ACE，再看子目录：

a_default  (os.mkdir)          Everyone 在   （继承）
c_755      (os.mkdir, 0o755)   Everyone 在   （继承）
b_700      (os.mkdir, 0o700)   Everyone 不在 D:P(A;OICI;FA;;;OW)(A;OICI;FA;;;SY)(A;OICI;FA;;;BA)

父目录给了什么都会被丢掉。这正是问题所在 —— 看仓库里这段注释（packages/sandbox/sandbox-windows-acl/src/index.ts:291-296）：

The restricted token's default DACL still names only the user's ambient SIDs — none of the restricting SIDs. Every NEW object the confined process creates ... takes its DACL from that default, so the write pass-2 check would deny pipe creation ...

于是 :303 调用 setTokenDefaultDaclGrant（定义在 token.ts:112）往 token default DACL 里合并一条 capability SID 的 full-access ACE。

这个 mode 恰好是那条假设的反例：os.mkdir(p, 0o700) 创建的对象不取 token default DACL，而是带一个固定的三元组（OWNER RIGHTS / SYSTEM / Administrators）且阻断继承。capability ACE 不在其中，也无法经继承补进来，所以所有 restricting SID（含创建者）在 pass-2 上被拒。这就是你说的那一步 —— 现在有测量，不是推断。

顺带解释你那两条无效规避：重定向 TMP/TEMP 和 dir= 改的都是路径，而这个 DACL 在对象创建那一刻就定死了，与路径无关；stat 报 0o777 也正常，Windows 上 mode 位本来就不反映 DACL。

对修法方向的影响

你的方向我同意，但理由要换一个：因为它是创建时写死 + 阻断继承，没有任何创建后的钩子能通用地补回来 —— 沙箱看不到那次 mkdir，也没有事件可靠地通知它 DACL 被替换了。所以能选的其实是：

• 让 pass-2 对受限进程自己创建/拥有的对象放宽（你说的「保持宽容」），代价是收紧程度下降；
• 或者提供一个受支持的临时目录入口，别让标准库 tempfile 直接落在受限 token 里创建。

取舍该由你们定，我不越界。

边界

我没有在受限 token 下跑 —— 这个 shell 是不受限的，所以我测的是「DACL 被替换」这一步（也就是你标未验证的那一步），不是 capability ACE 丢失本身。环境：Windows 11、Python 3.12.14、Get-Acl 读 SDDL、os.mkdir 各 mode 单跑。你原文里的 0d1f50007f 我没有复现。