[草案] 基于沙箱和授权的安全 Goja FS #1618
Description
在提问之前...
- 我填写了简短且清晰明确的标题，以便开发者在翻阅 issue 列表时能快速确定大致问题。而不是“一个建议”、“卡住了”等
- 我没有仔细查看这些选项，只是在无脑的勾选所有选项，请关闭这个 issue
- 我基本确定这是一个新功能/建议，而不是遇到了 bug（不确定的话请附上日志）
说说你遇到的问题？
计划为 Goja 环境引入文件系统 (FS) 操作能力。然而，直接暴露宿主机的 os 级 API 会带来严重的安全风险。
有什么好的想法？
隔离与路径校验
将每个插件限制在独立的隔离目录中，并执行严格的路径审计：
- 每个插件仅能访问默认数据路径（
data/default/extensions/<plugin_name>/）和需要手动授权的特定目录 - 强制执行
filepath.Clean与Rel校验，拦截向上跳转、绝对路径以及指向沙箱外部的符号链接 - 不暴露通用的文件句柄，提供替代的高级能力 API，禁止操作命名管道或设置执行标记
权限控制
这里有两个方案，可以选择，但个人觉得并行总体上更优（声明式权限解决准入，VFS解决隔离）
声明式权限控制：
- 插件必须在配置文件中显式声明权限（默认路径不需要声明，声明的路径需要经过 WebUI 手动授权）
- 采用默认拒绝原则，未声明的路径访问将在运行时直接拦截并在日志记录行为（这个要写到main.log）
- 支持进行一次性或持久化授权
虚拟文件系统：
- 基础映射（开箱即用）：
plugin://巴啦巴啦对应data/default/extensions/<plugin_name>/巴啦巴啦 - 高级映射（手动配置）：用户手动在 WebUI 上配置
虚拟路径 - 宿主路径的映射关系（会不会过于复杂了？）
运行保障与审计
为了确保系统的稳定性，建议增加以下限制：
- 设置单文件大小上限、插件总存储空间配额
- 对 I/O 调用进行速率限制并设置调用超时
- 记录所有 FS 调用（插件名、操作、虚拟路径、结果），并提供清晰的操作信息以便调试（单开一个log）
- 为每个插件实例维护一个 OpenedFiles 列表，必要时强制 Close 所有关联句柄
核心思路
主要是，让离开安全范围的操作都必须经过用户的手，这样可以堵住有关安全性的负面声音
选择是用户自己做的，损失用户自己承担.jpg
话虽如此，但作为开发者，目标是让用户想作死也难成功
其他内容
或许还需要某种机制，实现允许插件 A 在 B 预先同意的情况下访问插件 B 的路径的受控共享