解决 filebeat 在 Linux 上的 seccomp 问题一则
这一周断断续续花了好几天时间在 debug 一个软连接不能创建的问题，写此文章以记录。
背景
公司的日志平台采集器采用的比较流行的 filebeat。开始的版本是直接使用，新版本的采集器准备把它作为库引入，因为还要提供其它的功能。
问题
新采集器的其中一个功能就是会创建软连接/符号连接。 我在 macOS 完成编写此代码，功能一切正常。后来测试在基于 Ubuntu 搭建的 K8s Pipeline 里面完成。于是问题出现：在创建软连接时，始终报告：操作不允许（Operation not permitted）。 仔细检查代码后发现不是我的代码编写问题，并且我单独写了一个独立的功能在同样的环境创建软连接，一切正常。于是怀疑是创建软连接的功能和 filebeat 冲突了。 于是采用二分法加日志逐渐排查出问题所在的代码，定位问题在加载 seccomp 位置处：
1 2 3 |
|
这段代码加载之后，创建软连接变由成功变成操作不允许了。
Seccomp 是什么？
Seccomp，即 Secure Computing Mode，安全计算模式。
来自维基百科的解释如下：
seccomp (short for secure computing mode) is a computer security facility in the Linux kernel.
seccomp allows a process to make a one-way transition into a "secure" state where it cannot make any system calls except exit(), sigreturn(), read() and write() to already-open file descriptors.
Should it attempt any other system calls, the kernel will terminate the process with SIGKILL or SIGSYS.
它是自 Linux Kernel 3.17 开始引入的一项计算机安全设施/功能。这个功能可以让某进程单向地进入某种安全状态，在这种“安全状态”下：系统调用将会非常受限（见上述英文），尝试调用其它系统调用将会被内核直接杀掉进程。 “单向”是指一旦进入这种安全状态便不可退出。
seccomp-bpf 是对 seccomp 的扩展，它允许添加可配置的策略用于过滤系统调用。
Filebeat 拿它做什么了？
从 Filebeat 的官方文档来看，Filebeat 用它来过滤掉不必要的系统调用，最大化降低 Filebeat 的被攻击可能，即提高安全性。
Filebeat 一个文件日志采集器为什么在乎安全？因为：它直接运行在生产环境物理机上，如果出现安全隐患后果是不堪设想的。
Filebeat 为什么可能不安全？因为不是所有代码都是自己写的，必然引入了大量外部库的代码。没有人会把自己使用的外部库的代码全部 review 一遍吧？
Filebeat 的 seccomp 规则是可以完全关闭，或者是可配置性很强的。可以根据需要关闭或进行配置。
结束语
解决这个 bug 很花了不少时间。当然，主要问题出在不知道 seccomp 这项安全设施。