JianFeeeee
64f002cf66
上一步（1f48c5c）做出并验了边界工具；这一步把它接到 worker 的启动路径上， 于是「工作区档 = 本目录内可动」第一次由**内核**保证。 ## 规矩 - `plan` / `workspace` 档 → `am-sandbox --rw <会话工作区> … -- node worker.mjs` - `full` 档 → **不套**（发件人已声明全权，与档位表一致） - 拿不到会话工作区 → **不套**，并把理由打进日志（猜一个 `--rw` 会让"界内也写不了"） - 启动方式从 `fork` 换成 `spawn`（fork 只会 exec node，套不进中间那层）， `stdio` 里带 `'ipc'` 时 node 同样设 `NODE_CHANNEL_FD`，而沙箱是 exec 透传 ⇒ worker 的 `process.send` 照常可用 ## rw 清单是**实测得出**的，不是想当然 `lib/sandbox.js` 里那几条（会话工作区 / `os.tmpdir()` / `<agentDir>/sessions` / `AGENTMAIL_CONFIG_DIR` / `--rw-file /dev/null`）每条都对应一个真实的失败模式： 少了 `/dev/null`，`cmd 2>/dev/null` 一律 Permission denied（实测撞到）；少了 `<agentDir>/sessions`，回合结束保存会话就失败。真机验证：一个**真实的 pi agent** 跑在边界里，界内写成功、`/opt` 被拒（Permission denied），并如实汇报两者。 ## 两处必须收成一处的东西 - 会话工作区由**父进程**用与 worker 同一个函数解析（`resolveWorkspaceCwd`）—— 父进程猜一个目录当 rw、worker 落在另一个，症状是最难查的那一类 - `piMailFallback` 从 worker 挪进 `lib/workspace.js`：父进程要用同一个兜底值 ## 判据与踩到的坑 - `sandbox-launch.test.mjs` 6 条行为断言（套/不套、rw 里有 cwd 与 /dev/null、 `--` 之后是 node+worker、拿不到 cwd 时的理由、env 开关三态、rw 去重与只收存在的路径）。 变异"永不套沙箱" ⇒ 恰好那几条红。 - ★ 池测试原先会**随这台机器装没装 am-sandbox 而变** —— 那正是假绿的来源。 给 `createWorkerPool` 加了 `env` 注入点，测试显式 `AGENTMAIL_PI_SANDBOX=off`。 - ★ 给 import 起名 `spawn` 撞上本文件已有的 `function spawn(job)` ⇒ 自己调自己 （`RangeError: Maximum call stack size exceeded`，池测试当场红）。改名 `spawnProcess`。 - pi 桥全套 485 项通过。
93 lines
3.9 KiB
JavaScript
93 lines
3.9 KiB
JavaScript
/**
|
||
* 邮件寻址里的工作目录（三维地址 name@path.session 的 path 位）。
|
||
*
|
||
* 这个模块存在的理由是一次真实故障：插件建会话时用的 cwd 是自己拼的
|
||
* `~/.dsh/mail-sessions/mail-<uuid>` —— 每封邮件一个全新的空目录。
|
||
* DSH 与 opencode 都按 cwd 给会话分组，于是所有邮件会话既不属于任何项目、
|
||
* 彼此也不同组，界面上全落进「未分组」。
|
||
*
|
||
* path 位本来就是「希望它在哪儿干活」，插件只需照用。
|
||
*/
|
||
|
||
import { existsSync, mkdirSync, statSync } from 'node:fs';
|
||
import { homedir } from 'node:os';
|
||
import { isAbsolute, join, resolve } from 'node:path';
|
||
|
||
/**
|
||
* 没有可用 `to_workspace` 时的兜底目录（pi 专用）。
|
||
*
|
||
* 命名与 DSH 的 `mailSessionFallback` 同构，但目录名是 `.pi`：那个函数在 lib/ 下
|
||
* （三平台逐字节相同）写死了 `.dsh`，不能为 pi 改 —— pi 的会话落进 `~/.dsh/`
|
||
* 会让人以为是 DSH 在干活。
|
||
*
|
||
* 放在这里而不是 worker 里：**父进程要用同一个兜底值**。worker 的沙箱 rw 列表
|
||
* 由父进程算（`pool.mjs` → `lib/sandbox.js`），父进程猜一个目录而 worker 落在另一个，
|
||
* 症状是"界内也写不了"—— 为此把兜底收成一处，两边 import 同一个函数。
|
||
*/
|
||
export function piMailFallback(sessionKey) {
|
||
return join(homedir(), '.pi', 'mail-sessions', String(sessionKey || 'default'));
|
||
}
|
||
|
||
/**
|
||
* 校验寻址里的工作目录，不可用时返回调用方给的兜底。
|
||
*
|
||
* 决策顺序：
|
||
* 1. path 位是一个已存在的目录 → 直接用它（同 path 的多封邮件天然同组）
|
||
* 2. path 位非空但目录不存在 → **不创建**，返回兜底
|
||
* 3. path 位为空（地址写成 `dsh` 而不带 `@/path`）→ 兜底
|
||
*
|
||
* 为什么不给不存在的 path 建目录：那等于让一个笔误（`/home/porgram/x`）
|
||
* 在磁盘上落下一个真目录，而 Agent 会在里面一无所获地干活 ——
|
||
* 用户看到会话建起来了却什么都做不了，比明确落到兜底目录更难排查。
|
||
*
|
||
* 为什么拒绝相对路径：cwd 的相对基准是 harness 进程的启动目录，
|
||
* 那是个与邮件语义无关的量（systemd 下通常是 `/`）。
|
||
*
|
||
* 兜底由调用方给，因为各平台的兜底不同：opencode 有插件启动时的 directory
|
||
* 可用，DSH 没有、只能落到 `~/.dsh/mail-sessions/<会话>`（见 mailSessionFallback）。
|
||
*
|
||
* @param {string} workspace 事件里的 to_workspace
|
||
* @param {string} fallback 不可用时的兜底目录（可为空串 = 交给平台自己决定）
|
||
* @returns {{cwd: string, grouped: boolean}} grouped 为真表示落在了寻址指定的目录里
|
||
*/
|
||
export function resolveWorkspaceCwd(workspace, fallback) {
|
||
const raw = typeof workspace === 'string' ? workspace.trim() : '';
|
||
const fb = typeof fallback === 'string' ? fallback : '';
|
||
|
||
if (!raw || !isAbsolute(raw)) return { cwd: fb, grouped: false };
|
||
|
||
const abs = resolve(raw);
|
||
try {
|
||
if (existsSync(abs) && statSync(abs).isDirectory()) {
|
||
return { cwd: abs, grouped: true };
|
||
}
|
||
} catch {
|
||
// 权限不足等：当作不可用
|
||
}
|
||
return { cwd: fb, grouped: false };
|
||
}
|
||
|
||
/**
|
||
* 没有天然兜底的平台（DSH）用这个：`~/.dsh/mail-sessions/<会话 id>`。
|
||
* @param {string} sessionKey 会话标识
|
||
* @returns {string}
|
||
*/
|
||
export function mailSessionFallback(sessionKey) {
|
||
return join(homedir(), '.dsh', 'mail-sessions', String(sessionKey || 'default'));
|
||
}
|
||
|
||
/**
|
||
* 确保兜底目录存在。寻址指定的目录本来就存在（否则不会被选中），
|
||
* 只有兜底目录需要现建。
|
||
* @param {string} cwd resolveWorkspaceCwd 的结果
|
||
* @param {boolean} grouped 是否落在寻址指定的目录里
|
||
*/
|
||
export function ensureCwd(cwd, grouped) {
|
||
if (grouped || !cwd) return;
|
||
try {
|
||
mkdirSync(cwd, { recursive: true });
|
||
} catch {
|
||
// 建不出来就让 harness 自己报错，这里不该吞掉真实原因
|
||
}
|
||
}
|