fix(sandbox): init.sh 放行容器自身 loopback,mermaid 渲染真·终案(bump 0.58.10)

90 天 67 次 timeout 真凶:127.0.0.0/8 DROP 掐死 puppeteer 连 chromium 的
127.0.0.1 DevTools WebSocket(SYN DROP -> TCP 重试 ~127s,恒定 2m15s 超时
+ [object Object] + 零 CPU)。容器 127.0.0.1 是自己 netns 的 lo、到不了宿主,
DROP 无安全收益纯误伤。apply_blocklist 首条 -o lo ACCEPT(v6 同款),
127.0.0.11:53 豁免收编,127/8 与 ::1 DROP 降为 belt-and-suspenders。

服务器全款复刻容器实测:放行前小图也挂 2m14s;放行后小图 3.9s、
真实大图 -w 2800 -s 2 仅 5.2s(1 vCPU 渲大图慢亦为误判)。
之前 probe 全因 --entrypoint bash 绕过 init.sh 无 iptables 而全绿误判。

生效:镜像重建(init.sh COPY 层秒过)+ 回收存量容器。

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

CHANGELOG.md

@@ -5,6 +5,10 @@
 > 所以不是每个版本号都有条目。条目格式 `## <版本> — <日期>`,新条目加在最上面。
 > 工程口径的完整记录见 `PROGRESS.md` / git log。
 
+## 0.58.10 — 2026-07-12
+
+- 流程图 / 示意图(mermaid)渲染修复补全:0.58.8 之后实测仍会超时出不了图,根因是沙箱网络策略误伤了渲染引擎的内部通信,已修复;流程图、申报书 / 专利配图恢复正常,大尺寸图也可秒级出图。
+
 ## 0.58.8 — 2026-07-11
 
 - 修复流程图 / 示意图(mermaid)渲染:此前生成流程图、申报书 / 专利配图时渲染持续失败(任务反复重试仍出不了图),根因已定位并修复,重新部署后恢复正常。

DESIGN.md

@@ -195,7 +195,7 @@ scheduled_jobs(§8.5)   channel_bindings(§8.7,判别列+JSONB)
 **硬限制**:cgroup CPU/mem、pids-limit、exec timeout、并发数、read-only rootfs、tmpfs /tmp、no-new-privileges、drop ALL caps、非 root、`--shm-size`。**软配额**:按 user 计 DB(磁盘/LLM cost/wall time/流量/并发),超额 429。**网络**:默认 deny outbound,搜索抓取走宿主受控工具。
 
 **落地清单(Stage C 硬协议,实施按此对账)**:
-1. **网络 blocklist 硬编码段**(任一缺失=未完成):`169.254/16`(metadata)、loopback、内网三段、CGNAT `100.64/10`;**PG 实际 IP 单独再 block**(belt-and-suspenders)。
+1. **网络 blocklist 硬编码段**(任一缺失=未完成):`169.254/16`(metadata)、内网三段、CGNAT `100.64/10`;**PG 实际 IP 单独再 block**(belt-and-suspenders)。**容器自身 loopback(`-o lo`)显式放行**——netns 隔离下容器内 127.0.0.1 到不了宿主,DROP 它无安全收益且误伤容器内 IPC(2026-07 实锤:puppeteer↔chromium DevTools 走 127.0.0.1,被 DROP 导致 mermaid 渲染 90 天 0 成功)。
 2. **egress 模型**:容器 `HTTP(S)_PROXY` 走宿主 proxy + iptables DROP 其余 outbound(防 SDK 绕 env);proxy 做域名 allowlist(pypi/github/npm + 镜像)+ IP block + per-user 计量 + 审计。
 3. **进程组清理**:exec 套 `setsid`,timeout/cancel/正常三路径都 `kill -- -PGID`——防 `nohup` 派生 daemon 跨 exec 持久化成"跨对话后门"。
 4. **磁盘配额硬化时点**:首版应用层统计;**外部用户开放前必须升 xfs/ext4 project quota**(扫描间隙打满共享盘会拖死同节点)。

PROGRESS.md

@@ -23,6 +23,7 @@
 
 ### 2026-07
 
+- **07-12 / 0.58.10**:**mermaid 渲染真·终案:init.sh loopback DROP 掐死 puppeteer↔chromium**(task 9dcae061 四轮收官):0.58.8 部署后(镜像已 chromium .100、全新容器)复测仍恒定 ~2m15s 超时 + `[object Object]` + user CPU 近 0 → 复刻 pool 全款硬限制容器 bisect 定位:**init.sh `127.0.0.0/8 DROP` 挡掉 127.0.0.1 上的 DevTools WebSocket**(puppeteer 连 chromium 的控制通道),SYN DROP → TCP 重试打满 ~127s;容器内放行 `-o lo` 后小图 3.9s、真实大图原参数(`-w 2800 -s 2`)5.2s 出图——"1 vCPU 渲大图慢"亦为误判。**90 天 67 次 timeout 真凶是它**(chromium 坏版本只解释 26 次 launch fail);之前所有 probe 因 `--entrypoint bash` 绕过 init.sh 无 iptables,全绿误判三轮。修复:init.sh `apply_blocklist` 首条 `iptables -A OUTPUT -o lo -j ACCEPT`(v6 同款),原 127.0.0.11:53 DNS 豁免收编,`127.0.0.0/8`/`::1` DROP 降为 belt-and-suspenders 并修正"防回头打宿主"错误注释(容器 127.0.0.1 是自己 netns 的 lo,到不了宿主)。DESIGN §7.5 #1 红线段同步语义修正;RUN.md 故障兜底加终案条目(含 probe 大坑);probe_mermaid.sh 头部加 entrypoint-bypass 警示;CHANGELOG 面向用户补记。生效条件:镜像重建(init.sh 是 COPY 层,秒过)+ 回收存量容器。
 - **07-12 / 0.58.9**:**probe_mermaid.sh 用法注释修正**:临时容器跑法(case B)的 `docker run` 少了 `-i` —— 不带则容器 stdin 为空,bash 读 `/dev/stdin` 拿到空脚本**静默退出零输出**(服务器验证 0.58.8 时实测踩中,误以为探针跑完无异常)。仅注释修正,脚本本体不变。
 - **07-11 / 0.58.8**:**mermaid 渲染必崩最终定案 + 根治**(9dcae061 三轮排查收官):真凶 = 7-08 镜像重建时 apt 烤进的 chromium 点版本 `150.0.7871.46` 自带启动即崩 bug(int3 自杀、零日志、strace 无失败 syscall;上游 `.100` 已修,容器内 `--only-upgrade chromium` 实测复活出图)。排查中被逐一洗清的:沙箱 hardening 六件套、seccomp、AppArmor(Ubuntu 24.04 userns 限制在开但无关)、overcommit/ulimit/max_map_count、QEMU EPYC vCPU、镜像环境(纯净 trixie 对照 rc=0 反转定位)。修复两件套:Dockerfile ① `ARG CHROMIUM_REFRESH=<日期>` cache-bust 旋钮(chromium 出问题改日期重建,pip 大层不动);② **build 末尾渲染 canary**(真渲一张中文最小图,chromium/字体链坏则 build 当场失败——有它 7-08 就不会把坏版本带上线)。RUN.md 故障兜底条目改写为最终版(两根因 + 判别特征 + "别再猜 hardening")、CHANGELOG 面向用户记修复。部署:服务器重建镜像(新 ARG 自然打穿 chromium 层 cache)+ 回收存量容器。
 - **07-11 / 0.58.7**:round-3 第 3 步改从镜像内 puppeteer-core `revisions.js` 读 pinned 版本号直下(`@stable` tag 需先访问 Google 版本解析端点——被墙,上一轮三源全败的真因;`--base-url` 只管二进制不管解析),错误输出改 grep Error 行;加 `[步骤]` 参数支持只跑第 3 步。round-1/2 结论沉淀:崩溃无 FATAL 行(静默 CHECK)、gdb 栈无符号、CPU 无 pku/shstk/ibt(排除新安全特性交互)。

RUN.md

@@ -852,6 +852,7 @@ sudo xfs_quota -x -c "limit -p bhard=10g zcbot_<user_uuid>" /opt
 | 容器内 mmdc 渲 mermaid 报 `Failed to launch chromium` / `No usable sandbox` | chromium 在 `--cap-drop=ALL` 下自家 setuid sandbox 起不来,要 `--no-sandbox`。镜像已落 `/sandbox/puppeteer-config.json` + 给 mmdc 套了 wrapper 自动 `-p` 注入 ── **裸调 `mmdc -i x -o y` 就该成**。仍跪:`docker exec ... cat /usr/local/bin/mmdc` 看 wrapper 在不在(老镜像没 rebuild 则没有);或显式 `mmdc -p /sandbox/puppeteer-config.json -i x -o y` |
 | 容器内 mmdc 渲图卡到 **timeout** 而非报错 | chromium 默认用 `/dev/shm`,docker 不传 `--shm-size` 时只 64MB → 起不来一直挂。已在 `pool.py` 给 `docker run` 加 `--shm-size`(默 512m,env `ZCBOT_SANDBOX_SHM_SIZE` / yaml `sandbox.shm_size`)。**已 running 的旧容器不会自动生效**,重启 web + 等 idle 回收(或 `docker rm -f zcbot-sandbox-<uid>`)后新起的才带。实测脚本 `deploy/sandbox/probe_mermaid.sh` |
 | 容器内 mmdc 报 `Failed to launch the browser process: Code: null`(伴满屏 dbus 报错),wrapper / `-p` 配置都给了照崩;或直接跑 chromium `Trace/breakpoint trap (core dumped)` | 两个已实锤根因(2026-07 排查,dbus 报错全程是干扰项——成功时也打):**① `--pids-limit` 打满**(线程也计数,chromium 一次启动 ~150-200 线程 + shell 超时残留的进程树),特征是 stderr 有 `pthread_create: Resource temporarily unavailable (11)`;已默认调 1024(yaml `sandbox.pids_limit`),改后需等旧容器回收。**② apt 烤进镜像的 chromium 点版本自带崩溃 bug**(150.0.7871.46 启动即 int3 自杀、零日志、strace 无失败 syscall,上游 .100 已修),特征是全新容器首调即秒崩、`--only-upgrade chromium` 后就好;修法:改 Dockerfile `ARG CHROMIUM_REFRESH=<日期>` 重建(只刷 chromium 层),build 末尾 canary 从此在 build 时就拦住坏版本。判别工具:`probe_mermaid.sh`(shm/配置类)、`probe_chromium_bisect.sh`(hardening 逐 flag)、`probe_chromium_round3.sh`(FATAL/strace);hardening/AppArmor/seccomp/内存/ulimit 已全部排查无罪,别再从这些方向猜 |
+| 容器内 mmdc **恒定 ~2m15s 超时**(user CPU 近 0、输出 `[object Object]`、无产物),小图大图同时长;probe 脚本里却秒出图 | **init.sh 的 `127.0.0.0/8` DROP 掐死容器自身 loopback**(2026-07-12 终案,task 9dcae061;90 天 67 次 timeout 的真凶,chromium 坏版本只解释 26 次 launch fail):puppeteer 控 chromium 走 `127.0.0.1` 的 DevTools WebSocket,SYN 被 DROP → TCP 重试打满 ~127s 放弃。容器内 127.0.0.1 是自己 netns 的 lo、到不了宿主,DROP 纯误伤。已修:init.sh 首条 `-o lo -j ACCEPT`(**镜像重建 + 回收存量容器才生效**)。**probe 大坑**:`docker run --entrypoint bash` 起的容器不跑 init.sh、没有 iptables,验不出这类问题——复现线上必须默认 entrypoint 起容器再 `docker exec`;1 vCPU 渲 `-w 2800 -s 2` 大图实测仅 ~5s,"尺寸大导致超时"是误判 |
 | 模型不渲本地 mmdc、反复试 `mermaid.ink` 等在线渲图服务还失败 | 容器**有外网**(bridge+NAT),但 `mermaid.ink` 等**境外服务易被墙/不稳**,渲图不该依赖出站。docker backend 的 system prompt「运行环境」段(`agent_builder.py` 注入)已写明"渲图走本地 mmdc、别调在线服务";撞到多半是 prompt 没更新 / 跑在 host backend。渲 mermaid 一律 `mmdc -i x.md -o x.png` |
 | Export 报 "无可导出内容" | task 没 messages(只 system 不算);先发条消息再 export |
 | `NoSubtaskError: working_dir ... 前缀嵌套` | §7.4 no-subtask:同 user 不允许 working_dir 嵌套(child / parent)。**同项目多对话**用**完全相同**的 working_dir;否则改成 sibling(平级) |

core/__init__.py

@@ -1,3 +1,3 @@
 # zcbot 版本号单一事实源:web/app.py 的 FastAPI version、/healthz 返回、前端展示都引这里。
 # 改版本只动这一行。
-__version__ = "0.58.9"
+__version__ = "0.58.10"

deploy/sandbox/init.sh

@@ -40,22 +40,27 @@ apply_resolv_conf() {
 }
 
 apply_blocklist() {
-    # Docker embedded DNS 例外(必须在 127.0.0.0/8 DROP 前)──
+    # 容器 netns 自环放行(必须是第一条)── 容器里的 127.0.0.1 是容器**自己**的 lo,
-    # 容器内 /etc/resolv.conf 默写 `nameserver 127.0.0.11`,挡了所有域名解析全跪。
+    # bridge 网络下出不了 netns、到不了宿主,DROP 它防不到任何东西,只会误伤容器内
-    # 精准放行 53/udp + 53/tcp,不破坏 loopback DROP 基线(其他 127.0.0.0/8 仍挡)。
+    # 进程间 IPC。实锤事故(2026-07,task 9dcae061 终案):puppeteer 控制 chromium 走
-    iptables -A OUTPUT -d 127.0.0.11/32 -p udp --dport 53 -j ACCEPT
+    # 127.0.0.1 上的 DevTools WebSocket,被 127.0.0.0/8 DROP 掐死 → mmdc 渲染 90 天
-    iptables -A OUTPUT -d 127.0.0.11/32 -p tcp --dport 53 -j ACCEPT
+    # 0 成功。特征:恒定 ~2m15s 超时(TCP SYN 重试打满)、user CPU 近 0、[object Object];
+    # 且各 probe 因 `--entrypoint bash` 绕过本脚本没跑 iptables,全都"能渲"→ 长期误判。
+    # docker embedded DNS(127.0.0.11:53)也走 lo,原先单独的 53 端口豁免一并收编。
+    iptables -A OUTPUT -o lo -j ACCEPT
 
     # §7.5 #1 红线段(任一缺失视为 Stage C 未完成):
     iptables -A OUTPUT -d 169.254.0.0/16 -j DROP    # cloud metadata (Capital One 2019 SSRF)
-    iptables -A OUTPUT -d 127.0.0.0/8   -j DROP    # IPv4 loopback (容器回头打宿主端口;DNS 已上面例外)
+    iptables -A OUTPUT -d 127.0.0.0/8   -j DROP    # 非 lo 出口的 127/8(正常路由不存在,belt-and-suspenders;自环已在首条放行)
     iptables -A OUTPUT -d 10.0.0.0/8    -j DROP    # 内网段 A
     iptables -A OUTPUT -d 172.16.0.0/12 -j DROP    # 内网段 B(Docker 默认 bridge 网段在此)
     iptables -A OUTPUT -d 192.168.0.0/16 -j DROP   # 内网段 C
     iptables -A OUTPUT -d 100.64.0.0/10 -j DROP    # CGNAT(云平台常用)
 
-    # IPv6 loopback ── ip6tables 在某些精简镜像 / sysctl ipv6.disable_ipv6=1 下不可用,
+    # IPv6 loopback ── 同 v4:自环放行在前(chromium/node 偶有 localhost→::1 解析路径),
-    # 失败降级为 warn(IPv6 没起的话本来也打不通,容忍)
+    # ::1 DROP 留作 belt-and-suspenders。ip6tables 在某些精简镜像 / sysctl
+    # ipv6.disable_ipv6=1 下不可用,失败降级为 warn(IPv6 没起的话本来也打不通,容忍)
+    ip6tables -A OUTPUT -o lo -j ACCEPT 2>/dev/null || true
     if ! ip6tables -A OUTPUT -d ::1 -j DROP 2>/dev/null; then
         echo "[init] ip6tables ::1 rule skipped (ip6tables unavailable or v6 disabled)" >&2
     fi

deploy/sandbox/probe_mermaid.sh

@@ -1,5 +1,8 @@
 #!/usr/bin/env bash
 # 在 sandbox 容器里实测 mmdc/chromium：区分「chromium 缺包」vs「纯启动超时(/dev/shm 64MB)」。
+# !!大坑(2026-07-12 实锤):本脚本 B 跑法 `--entrypoint bash` 会**绕过 init.sh、不配 iptables**,
+# 验不出 blocklist 类问题(loopback DROP 曾掐死 puppeteer↔chromium,probe 全绿线上全挂)。
+# 要贴线上环境:用默认 entrypoint 起容器(init.sh 跑完 iptables)再 docker exec 进去测。
 # 用法(服务器上,任选其一):
 #   A) 进一个活着的 per-user 容器(最贴真,复用线上 64MB /dev/shm 默认):
 #        C=$(docker ps --filter "label=zcbot.product=sandbox" --format '{{.Names}}' | head -1)