[Bug] 任意 skill 子进程崩溃产生的 core dump 会污染用户 workspace（平台级隔离缺失）

[limin2199]

Labels（建议）：bug · deployment · sandbox · security

一句话：Yuxi 核心代码本身不调用 Chromium，崩溃来自某个 skill；但 Yuxi 默认部署没有在运行 skill 的容器上禁用 core dump，且沙盒以用户 workspace 为工作目录（cwd），导致任何 skill 子进程崩溃都会把 core.<PID> 写进用户个人空间。这是平台层面的隔离/健壮性缺陷，与具体是哪个 skill 触发无关。

---

1. 背景 / 责任边界（重要）

• Chromium 崩溃的「直接原因」在 skill 侧：例如 ppt-master skill 的脚本 extract_svg_pictures.py / visual_review.py 用 playwright.chromium.launch(headless=True) 且未加 --no-sandbox --disable-dev-shm-usage，在容器 root 环境下 SIGSEGV。
• 但 ppt-master 是独立安装/投影的 skill（docker/volumes/yuxi/skill-projections/admin/ppt-master/，不在 xerrors/Yuxi 仓库 git 跟踪内），其 Chromium 启动参数的修复属于该 skill 维护者的责任，不在本仓库范围。
• 本 issue 报的是 Yuxi 平台的缺陷：无论哪个 skill 崩溃，平台都不该让崩溃产物落进用户数据。即便所有 skill 都完美，未来任何第三方 skill 的一个崩溃仍会复现此问题。

---

2. 现象 / Symptom

Yuxi 用户的「个人空间 / 项目 workspace」目录里出现大量 core.<PID> 文件：

• 数量：336 个
• 单个大小：固定 24,969,216 字节（≈23.8 MB）
• 合计：≈ 8.4 GB
• 路径示例：<user-data>/threads/shared/admin/workspace/projects/<uuid>/core.75877
• 时间戳集中在 agent 运行时段

这些 core.* 不是用户内容，却落进项目目录，污染 workspace、占用磁盘、易被误当数据文件。

---

3. 根因分析 / Root cause（平台侧）

3.1 Yuxi 默认未在运行 skill 的容器上限制 core dump

• 实测挂载了 /app/user-data（用户 workspace）并运行 skill / 沙盒代码的服务包括 api / worker / sandbox-provisioner 等（docker-compose.yml:56,75,106,123,153,165,179）。
• 这些服务的容器 ulimit -c = unlimited（继承自宿主）。
• compose 里仅有 mineru-api 服务设置了 ulimits（memlock/stack，docker-compose.yml:420 / prod :366），而运行 skill 的服务未设置 core 限制。

3.2 沙盒进程 cwd = 用户 workspace → core 落到用户数据

• SANDBOX_VIRTUAL_PATH_PREFIX=/home/gem/user-data + volume ./docker/volumes/yuxi/threads:/app/user-data，skill 脚本以项目 workspace 目录为 cwd 运行。
• 宿主机 kernel.core_pattern = |/usr/libexec/abrt-hook-ccpp（abrt 管道）。abrt 在容器内连不到 abrtd、也写不了 /var/spool/abrt，内核回退为在崩溃进程 cwd 写 core.PID → 直接写进用户 workspace。

3.3 任意 skill 都可触发

Yuxi 核心不调用 Chromium（源码 0 处 chromium.launch）。但 skill 生态里的脚本会（Playwright / 无头浏览器 / 任意会崩的原生子进程）。只要运行 skill 的容器 ulimit -c 不限制、cwd 指向 user-data，任何一次崩溃都会污染用户空间。ppt-master 只是当前暴露的触发器之一。

---

4. 复现步骤 / Reproduction

1. 默认 compose 部署 Yuxi（未改 ulimits）。
2. 在对话里触发某个会拉起无头 Chromium / 原生子进程的 skill（如 ppt-master 的 SVG / 可视化渲染）。
3. 进入对应项目 workspace：docker/volumes/yuxi/threads/.../workspace/projects/<uuid>/。
4. 观察：目录中出现 core.<PID>，且每次渲染都新增。

证据：

$ file core.75877
core.75877: ELF 64-bit LSB core file ...
  from '/usr/local/bin/browser ...'
  execfn: '/opt/chromium.org/chromium/chrome'     # 崩溃=Playwright 自带 Chromium

$ cat /var/spool/abrt/last-ccpp
... /opt/chromium.org/chromium/chrome ...         # abrt 交叉印证

$ docker exec <运行skill的容器> sh -c 'ulimit -c'
unlimited                                        # 未限制 core

$ grep -n -A3 "ulimits:" docker-compose.yml
420:    ulimits:        # 仅 mineru-api 有；api/worker/sandbox 无 core 限制
421-      memlock: -1
422-      stack: 67108864

---

5. 影响 / Impact

• 用户 workspace 被无关大体积 core.* 污染（8.4 GB 级），干扰文件浏览、备份、版本管理。
• 长期运行缓慢吃满磁盘（容量与 inode）。
• 本质是「平台默认无 core 限制 + 沙盒 cwd 直指用户数据」的隔离缺失，属平台健壮性/多租户安全范畴。

---

6. 建议修复（Yuxi 平台侧，本仓库范围）

6.1 治本（推荐）：在运行 skill / 沙盒的容器统一禁用 core dump

在挂载了 /app/user-data 并运行 skill / 沙盒代码的服务（api / worker / sandbox-provisioner 等）增加：

services:
  api:
    ulimits:
      core: 0          # soft 与 hard 同时置 0，禁止写 core
  worker:
    ulimits:
      core: 0
  sandbox-provisioner:
    ulimits:
      core: 0

或在基础镜像层把 kernel.core_pattern 指向 /dev/null / 临时目录，从镜像根治。

6.2 加固（可选）：沙盒子进程 cwd 与用户数据隔离

让 skill / 沙盒脚本在 user-data 之外的临时/scratch 目录执行，即便产生 core 也不污染用户空间（进一步降低误读/误删风险）。

---

7. 不在本仓库范围的修复（供 skill 维护者参考）

触发本次现象的 ppt-master skill 应在其 chromium.launch(...) 调用处补容器必要参数（属该 skill 自身仓库的修复）：

browser = playwright.chromium.launch(
    headless=True,
    args=["--no-sandbox", "--disable-dev-shm-usage", "--disable-gpu"],
)

---

8. 参考 / References

• 相关文件（部署卷路径；均非 Yuxi 仓库源码）：
  • docker/volumes/yuxi/skill-projections/admin/ppt-master/scripts/extract_svg_pictures.py:307
  • docker/volumes/yuxi/skill-projections/admin/ppt-master/scripts/visual_review.py:182
• compose：docker-compose.yml（:420 ulimits / :56,75,106,... user-data 挂载）、docker-compose.prod.yml（:366）
• 验证：git ls-files | grep ppt-master 为空 → ppt-master 不在仓库跟踪内；Yuxi 源码树 0 处 chromium.launch