Repository navigation
Replies: 5 comments
|
你的核心断言成立，而且我把它钉到了具体行：命中缓存后没有任何存在性复核。但有两处要收紧，其中一处会直接影响报告的可采信度。 1. 无探测、无自愈 —— 确认
const existing = this.tempCapabilities.get(key)
if (existing !== undefined) return existing
const tempDir = mkdtempSync(join(tmpdir(), 'dsh-'))⇒ 命中缓存直接返回，没有 runner 侧 fail(`${label} is not an existing directory: ${path}`)（调用点 分类路径也对上： 第二处只拒不自愈： 2.
|
Reproduction still on 0.2.1-rc.5, plus evidence on why the directory disappearsAdding two things this thread does not yet have: a confirmed repro on the current build, and the 1. Still reproduces on 0.2.1-rc.5 (Windows 11)2. A diagnostic signature that separates this bug from the 0xC0000142 familyThis thread and the many
So: if file tools still work and only shell dies instantly with 3. Survey of
|
| Directory | created | last modified | entries |
|---|---|---|---|
dsh-9zP75T |
09:38:11 | 10:23:17 | 8 |
dsh-acl-locks |
05:34:02 | 10:42:39 | 12 |
dsh-AYZFyL |
05:35:01 | 05:45:38 | 2 |
dsh-bKH8TT |
10:21:38 | 10:23:09 | 0 |
dsh-DkFm0d |
10:42:39 | 10:49:07 | 0 |
dsh-mAewhL |
09:49:41 | 09:49:48 | 0 |
dsh-spill-heHzAi |
05:35:13 | 10:44:13 | 11 |
dsh-ZhxUsI |
10:42:39 | 10:48:18 | 0 |
| … (3 more) |
Observations:
TEMP,TMPandos.tmpdir()all resolve to the same defaultC:\Users\<user>\AppData\Local\Temp— so this is not the "TEMP moved to a data volume" class from [Bug] Windows: TEMP moved to a data volume makes every workspace-write command fail before spawn #10765.- The directory is removed while the app keeps running; no restart is involved.
- Searching the shipped
app.asarfor a startup sweep overreaddirSync(tmpdir(...))/readdir(tmpdir(...))yields 0 hits. DSH has no code that prunesdsh-*directories. - The only removal path in the provider is
revokeAclGrants(), wired exclusively to fiber teardown (ctx.effect(() => () => this.revokeAclGrants())), so it cannot run for a live provider.
⇒ The deletion comes from outside the process (temp cleaner, AV, Storage Sense, enterprise cleanup script). That part is environmental, and DSH is not "wrong" to have its directory removed. The defect is the reaction to it: the path is cached forever, never re-validated, never rebuilt, and the only surfaced remedy is to drop the security boundary.
4. Why it never self-heals
materializeAclGrant() caches per [sessionId, workspaceRoot]:
const existing = this.tempCapabilities.get(key);
if (existing !== void 0) return existing; // no existsSync / statSync
const tempDir = mkdtempSync(join(tmpdir(), "dsh-"));Every subsequent confine() re-passes the stale --temp, the runner fails at requireDirectory('--temp', …), exits 127, and the failure is classified as a runner failure (not a denial) — so it propagates as SandboxUnavailableError every single time. Deterministic, not racy.
5. One more annoyance: the error message itself
The failure message hands a Windows user Linux advice first (Install bubblewrap or run a Landlock-enforcing kernel), then macOS (ensure sandbox-exec is usable), and only at the very end the one line that actually describes the problem (windows-acl-run: --temp is not an existing directory). Since the runner signature windows-acl-run: already identifies the platform unambiguously, the message could lead with the real cause and the platform-relevant remedy, and skip the other platforms entirely.
6. Suggested minimal fix (narrower than a full re-init)
const existing = this.tempCapabilities.get(key);
if (existing !== undefined) {
try {
if (statSync(existing.dir).isDirectory()) return existing;
} catch {}
// stale: drop the grant and fall through to re-create
try { existing.grant.dispose(); } catch {}
this.tempCapabilities.delete(key);
}
const tempDir = mkdtempSync(join(tmpdir(), 'dsh-'));This is cheap (one statSync on a cached hit) and makes the state self-healing without touching the runner. A one-shot retry inside the runner would additionally cover the race where deletion happens mid-flight.
Both items in the expected-behaviour list of the original report would be satisfied by this; the re-init path already exists in materializeAclGrant, it is just unreachable once the key is cached.
|
你那条 rc.5 复现对得上今天 master 的代码：位置没变，行号是 代码还是那样： 你补的两条我并进结论： 结论变化 范围从"0.2.0-rc.2 上有一个缓存不复核的洞"扩到"0.2.1-rc.5 仍在"，而且它不需要第三方插件参与。修法没变，还是那一条：命中缓存前确认 下一步 如果你们能拿到 host 日志里 只读了 master |
|
大概就是dsh的沙箱策略比较严格，要一个系统级别的沙箱，但是这个东西你得找windows去改文件权限什么的。 |
Follow-up: quantified evidence from the session log (decoded)PerryLink asked for the host-log line before the runner failure to identify who deleted the directory. The session event log doesn't carry host stderr, so that line isn't in it — but the log does yield hard numbers this thread didn't have yet. Decoded from 1. Denial timeline splits into two windows — matching the two mode switches
Key fact: the same cached 2. Total lockout confirmed quantitativelyWindow A: 3 shell denials, 13 successful non-shell tool results in the same window — file read/write/edit kept working the whole time. Every 3. Job latency confirms the pre-spawn classificationFirst denial: 4. The denial string, complete and untruncatedNote the platform-advice ordering issue mentioned in my previous comment is clearly visible here: Windows users read Linux/macOS advice first, the actual cause is the last line. 5. On "who deleted the directory" — still open, one more data pointThe host-side stderr line PerryLink asked for isn't persisted anywhere I can find (checked Decoding script is trivial if maintainers want to run it on their own logs: read the |
Uh oh!
There was an error while loading. Please reload this page.
问题描述
在 Windows 上使用
workspace-write模式时，沙箱 runner 报告会话临时目录不存在。此后，同一会话中的所有命令均失败，包括Test-Path等只读命令，重复执行也无法恢复。环境
0.2.0-rc.2，nightly 通道10.0.26200，x64workspace-write实际错误
以下用户路径已脱敏：
出现过程
workspace-write模式下正常使用会话。目前尚未确认临时目录为何消失，也未确认命令中断是否是触发原因。已确认的现象是：目录缺失后，会话持续引用该路径，受控执行无法恢复。
本次排查中，系统
%TEMP%目录仍存在，未发现其访问权限异常。切换为
danger-full-access后可以继续执行，但这会改变原有的安全边界，不能视为沙箱功能恢复。初步分析
根据包内文档：
Windows ACL provider 会为活跃的会话/工作区创建私有临时目录，并将
--temp与对应的--temp-write-sid传给 runner。目录缺失时，runner 会报告失败。从本次现象看，可能是 provider 缓存的临时目录路径失效后，缺少资源重新初始化或恢复机制。具体原因仍需维护者确认。
另外，当前错误提示同时包含 Linux、macOS 和 Windows 的建议，而真正与本次故障相关的
--temp is not an existing directory位于末尾，不利于用户定位问题。期望行为
该问题的主要影响是：一个会话临时目录失效，会导致整个会话持续失去受控执行能力。
All reactions