加载失败
讨论源于对一篇比较 FreeBSD Capsicum（FreeBSD 的基于能力的进程沙箱）与 Linux seccomp（Linux 的系统调用过滤机制）的文章的评论。有人分享工程经验：可以用 seccomp 在 Linux 上实现 Capsicum 式的白名单—先打开特定资源然后封存策略，但实现繁琐且 API 不友好，适合接口固定的容器过滤器（使用 FIFOs（命名管道）做 IPC/日志/上报）。另有评论指出这种方法易受 glibc（GNU C library）及运行时行为的影响（例如 printf 首次触发 newfstatat、dlopen、或 poll/select/epoll 切换），因此对长期可靠性存疑。Community 里有对 Landlock 的期待——希望内核提供更原生的 capability/白名单原语；同时大量读者抱怨文章站点可读性差并怀疑内容由 AI 生成。
有评论者分享他们为客户实现的库，展示在 Linux 上用 seccomp 模拟 Capsicum 的可行路径：先打开需要的资源（stdin/stdout/stderr、若干 pipe、socket 等），再用 seccomp 限制对这些特定 file descriptor 的 read/write 等调用，最后封存自身以防止后续更改。整体思路相当于把 Capsicum 的白名单/能力模型移植到 seccomp，但实现需要大量手工配置且现有 API 并不优雅。作者当时之所以能较好地锁定权限，是因为目标场景是容器内固定接口的过滤器，利用 FIFOs（命名管道）做 IPC、日志和上报，接口一致性降低了复杂度。
另一类评论强调，seccomp 严格白名单容易被运行时库和环境的不可预测行为打破，从而导致长期维护困难。具体例子包括：首次调用 printf() 会隐式触发 newfstatat()；glibc（GNU C library）可能根据配置或运行时条件 dlopen 额外模块；代码在文件描述符增多时可能从 poll() 切换到 select() 或 epoll()，这些都会触发未被提前列举的系统调用。因此有人认为基于 seccomp 的白名单方法在现实长期部署中风险较高，相关博客甚至把 seccomp 描述为“unsafe at any speed”，并引出对更稳健方案的需求。
不少评论把目光投向 Landlock（Linux 的较新 LSM）或直接希望 Linux 出现 Capsicum 式的原语，认为这比用 seccomp 拼装更合适。有人明确表示 Landlock 更适用于这类隔离场景并建议在 Landlock 成熟后做后续比较，显示社区对内核级、更友好的能力模型的期待。总体观点是：虽然工程上可以用 seccomp 模拟能力沙箱，但更理想的是内核层提供专门的 capability/白名单接口以降低复杂度和易错性。
大量评论抱怨文章站点的可读性问题：配色偏灰导致难读、字体模糊、在无 JavaScript 时页面循环刷新、页面嵌入游戏和图表破坏了阅读模式，这些 UI 问题影响了技术讨论的接受度。另有评论声称整站（约 90 篇文章）在短期内由 AI 生成，怀疑背后作者身份和写作目的，认为是“resume-boosting AI slop”。同时有人指出基本站点配置如 HTTPS 都存在问题，读者因此对内容质量与可信度提出批评并要求更透明的出处说明。
[来源1] [来源2] [来源3] [来源4] [来源5] [来源6] [来源7] [来源8]
Capsicum: Capsicum（FreeBSD 的能力机制）是一种基于 capability 的沙箱模型，把进程置于 capability mode 后只能通过已有的 file descriptor 或 capability 访问资源，从而避免依赖路径名或全局权限检查。
seccomp: seccomp（secure computing mode，Linux 的系统调用过滤机制）允许内核基于白名单或 BPF 规则限制进程可执行的系统调用，用于瘦身沙箱，但需要详尽列举允许的 syscall，易受运行时行为影响。
Landlock: Landlock（Linux Security Module，LSM）是 Linux 上较新的非特权沙箱机制，采用基于路径和规则的访问控制，目标是为用户空间提供更可控的文件/路径限制，作为比纯 syscall 白名单更友好的隔离选项。