加载失败
这篇讨论围绕 Flatpak（Linux 上的应用沙箱与打包系统）的一则安全问题：如果系统先验证路径字符串，再在稍后真正打开文件，就可能被 symlink 等手法把目标换掉。评论里说，修复不只是改一个函数，而是要沿着 portal（桌面应用到系统服务的受控接口）到 bubblewrap（Flatpak 常用的 Linux 沙箱工具）的整条链路，把 path string 改成 fd（文件描述符）。这也被拿来类比 AI agent 的文件操作和命令执行沙箱：只要允许它们处理脚本、链接或嵌套命令，单靠白名单很难彻底可靠。讨论同时延伸到安装器和 root 权限流程，强调准备阶段留下的内容可能在执行阶段被放大成任意写入或任意执行。
评论里最强烈的共识是，基于路径白名单的应用层沙箱很脆弱，symlink 之类的手法就可能把受信任路径偷偷指向别处。有人把这个风险直接类比到 AI agent 的文件读写和 shell 命令控制：只要允许它创建链接、处理脚本或递归分析命令，就很难靠字符串判断真实行为。也有人因此表示不信任那些宣称自己已经沙箱化的实现，宁愿把 CLI 代码放进完整 VM 里跑，而不是只依赖 container。另一条回复则更强硬，认为只要试图分析会被执行的命令字符串，就会陷入无法穷尽的安全兔子洞。
有评论质疑，这类问题是不是默认攻击者已经能按路径修改文件，因此更像提权链而不是独立漏洞。回应指出，现实里的 installer 或打包流程常分成下载准备和执行落盘两段，前一段可能在低权限或受限环境里处理材料，后一段却会在 root 权限下复制或启动。问题就在于前一步留下的内容，被后一步当成可信目标或可执行文件，最终导致任意覆盖或任意代码执行。有人还拿 root 运行的 docker daemon 之类场景来说明，这种替别人动文件的模式本身就很危险。
另一个明确的修复思路是，不要再传递 path，而是先按调用者权限 open 文件，再把得到的 fd 一路传下去。评论里提到，Flatpak 的实际修复不是改一个函数，而是审计从 portal request 到 bubblewrap execution 的整条调用链，把所有 path string 都换成 fd。这样做的目标是绕开路径重解析带来的歧义，也避免 symlink 在检查后被替换。这个方向把问题从猜这个字符串指向哪里，变成我已经拿到了具体对象。
也有人提醒不要把所有安全问题都上升成文件系统 API 有罪。这个观点认为，真正该修的是具体代码和权限边界，标准做法包括系统级加固与正确的 Unix 用户隔离。换句话说，问题往往是程序自己把不可信输入当成了可信路径，而不是 open file 这个概念天生不可用。它反对的是过度放大风险，而不是否认这里确实存在漏洞。
symlink（符号链接）: 一种把一个路径指向另一个目标的链接，容易被用来绕过基于路径的校验。
fd（file descriptor，文件描述符）: 进程已打开文件后的句柄，后续操作基于这个具体对象而不是再次解析路径。
sandbox（沙箱）: 限制进程权限的隔离环境；如果只做路径白名单，仍可能被绕过。
Flatpak: Linux 上的应用沙箱与打包系统，常用于让桌面应用在受限环境中运行。
bubblewrap: Flatpak 常用的 Linux 沙箱工具，用来启动和隔离受限进程。