[Bug][Windows sandbox] tempfile.mkdtemp creates unwritable directories

[iostwish3]

Summary
On the windows-acl sandbox backend (workspace-write mode), a confined process that creates a directory with Python's tempfile.mkdtemp() cannot write files inside that directory, even though the directory was created by the process itself. The same operation succeeds with os.makedirs(), and everything works under danger-full-access.
This breaks any test suite or tooling that relies on tempfile.TemporaryDirectory / mkdtemp (e.g. unittest's TemporaryDirectory) when running inside the DSH sandbox: every such test fails with PermissionError [WinError 5].

Environment
OS: Windows 10 (build 26200)
DSH: developer preview, latest master (apps/cli run via node --import tsx/esm apps/cli/src/bin.ts web)
Sandbox backend: windows-acl (ACL restricted-token runner), mode workspace-write
Python: 3.14
Shell: PowerShell 7.6 (via the pwsh tool)

Reproduction
Minimal repro inside a confined workspace-write pwsh:

import tempfile, os

d = tempfile.mkdtemp(prefix="probe-")
print("created:", d)
with open(os.path.join(d, "x.txt"), "w") as f:
f.write("hi")

Result:
PermissionError: [Errno 13] Permission denied: 'D:\Temp\dsh-XXX\probe-....\x.txt'

Interesting details observed during the investigation:

• os.makedirs(...) then writing into it succeeds in the same confined process.
• On the failing mkdtemp directory, even icacls reports Access is denied — the confined process cannot read the ACL of a directory it just created.
• The sandbox runner rewrites TMP/TEMP for the child to the private sandbox directory %TEMP%\dsh-* (sandbox-windows-acl/src/runner.ts), so any standard-library temp usage lands there.

Expected behavior
A confined workspace-write process should be able to create a directory (via mkdtemp or otherwise) under the granted temp area and write into it, since that is exactly the temp area the sandbox itself assigns.

Root cause (as far as I can tell)
The windows-acl backend grants write access through capability-SID ACEs that rely on DACL inheritance:

The workspace and the private temp dir carry an ACE like S-1-4-...:(OI)(CI)(W,D,DC) for a capability SID included in the restricted token's restricting list.

New objects created by the confined process must therefore inherit that ACE to be writable by the same process.

token.ts's setTokenDefaultDaclGrant merges a full-access ACE into the token's default DACL, but that only covers objects created without an explicit security descriptor (e.g. anonymous pipes). The comment in the code explicitly scopes it to "a new anonymous pipe (child stdio)".

Python's tempfile.mkdtemp() on Windows creates the directory with an explicit security descriptor, which means the new directory's DACL does not inherit the parent's capability-SID ACE. The result is a directory whose DACL names only the user's ambient SIDs — the confined process (whose token is restricted) cannot access it, not even to read its ACL.

Confirmed by ACL comparison:
makedirs-created dir: S-1-4-68446650-...:(I)(OI)(CI)(W,D,DC) <- capability SID inherited, writable
mkdtemp-created dir: icacls -> "Access is denied" <- capability SID lost, unwritable

Suggested fix
Option A (sandbox side): when materializing the temp grant, also make the capability ACE inheritable onto objects created with explicit security descriptors — e.g. by also merging an inheritable ACE into the token's default DACL with (OI)(CI) flags, or by re-applying the DACL on new child directories under the private temp root.

Option B (documentation): at minimum, document this limitation for the windows-acl backend and advise Python users to avoid mkdtemp inside the sandbox (or to re-DACL created temp dirs).

Workaround I'm currently using
A sitecustomize.py in the project that detects the DSH sandbox (via tempfile.gettempdir() containing dsh-) and replaces tempfile.mkdtemp with an os.makedirs-based implementation, which inherits the ACL correctly. Happy to share the full patch if useful.

[PerryLink]

这条的机制我可以在你的原帖基础上补上缺的那一环，而且它正好解释你观察到的那个不对称：os.makedirs() 行、tempfile.mkdtemp() 不行。

1. mkdtemp 内部就是 mkdir(mode=0o700)

在本机 Python 上查 tempfile.mkdtemp 的源码，那一行是：

_os.mkdir(file, 0o700)

2. 而 0o700 恰好是 Windows 上唯一会替换 DACL 的那个 mode

我在 Windows 11 / Python 3.12.14 上逐个 mode 实测（用 Get-Acl 读 SDDL）：

os.mkdir(p)                      继承 DACL
os.mkdir(p, 0o755/0o750/0o711/0o600/0o500/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 未被触碰

D:P = 保护（阻断继承），三条 ACE 全是显式的，trustee 是 OWNER RIGHTS / SYSTEM / Administrators。进一步验证：给父目录加一条可继承的 Everyone ACE，os.mkdir(p) 与 0o755 的子目录都有 Everyone，而 0o700 的子目录没有 —— 所以它不是"照抄父目录"，而是换成一个固定集合。

⇒ 这解释了你的全部观察：

• os.makedirs() 行：它用默认 mode，保留继承 DACL，所以沙箱给新对象补的 capability ACE 还在；
• mkdtemp() 不行：0o700 把 DACL 换成固定三元组并阻断继承，capability ACE 既不在其中、也无法经继承补进来，于是连创建者自己都被 write pass-2 拒绝；
• icacls 报 Access is denied：同一个原因 —— 受限进程连该目录的 ACL 都读不到；
• danger-full-access 下一切正常：那条路径不装 capability/restricting 机制。

3. 这条为什么值得上游修

沙箱的设计前提写在 packages/sandbox/sandbox-windows-acl/src/index.ts:291-296：受限 token 的 default DACL 只含用户的环境 SID，所以代码显式把某个 capability SID 的 full-access ACE 合并进 default DACL，让新对象的 DACL 能通过 pass-2。而 os.mkdir(p, 0o700) 是这条前提的反例：它创建的对象不取 default DACL。⇒ 沙箱看不见那次 mkdir，没有任何创建后的钩子能通用地补回来。

可用的规避（在修复前）：在受限进程里不要用 tempfile.mkdtemp / TemporaryDirectory，改用 os.makedirs() 建目录、或用不传 mode 的 os.mkdir；测试套件里可以给 tempfile 打个 shim。

边界：读的是 c36a83ff6b（dsh-v0.1.7-alpha.1）的沙箱源码与注释；DACL 那组数据是我在本机实测的（不是从代码推出），但我没有在你的沙箱版本上复现 —— 你报的是 8 月中旬的 master，那之后沙箱加过 Low 完整性标签等改动，所以"当时"的具体授权路径我没有逐一核对。你原帖里还有一句被截断的"the sandbox runner rewrites …"，如果那是另一条独立线索，请贴全。