> 5.2 把"系统调用过滤器有没有装成功"变成 bootstrap check：过滤器开着但没装上，节点拒绝启动。同时 `bootstrap.seccomp` 改成 `bootstrap.system_call_filter`（旧名在 5.x 仍可用，6.0 删除）。官方 bootstrap checks 文档对这项检查的通过条件写得很直接：要么修好让过滤器能装上，要么自担风险把过滤器关掉——**一步，不是两步**。本文按 v5.6.16 源码把检查的实现条件、各系统上被拦的系统调用、装不上的常见原因列出来。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845)。

来源和边界先交代：本文的依据出自 v5.6.16 标签下的官方文件（`migrate_5_2.asciidoc`、`SystemCallFilter.java`、`bootstrap-checks.asciidoc`），文中引用的原文均来自这些文件。示例取自官方示例；哪些是文档写明、哪些是我的推断，正文里逐处标注。

实测环境：本地另起一个 Elasticsearch 5.6.16 单节点实例（官方 tar 包，端口 9200，独立 `path.data`），按默认配置启动，未改动 bootstrap 参数。文末实测小节里的命令与响应均取自这些实例。

![01-migrate_5_2](https://developer.qcloudimg.com/http-save/yehe-7348459/c55a1bd129960a770050ea6e9e5c4c65.png)

*图 1：官方文件 migrate_5_2.asciidoc（v5.6.16 标签）。来源：GitHub elastic/elasticsearch v5.6.16 migrate_5_2.asciidoc*

## 从"警告一下"到"拒绝启动"

5.2 迁移文档（[migrate_5_2.asciidoc 第 9–16 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/docs/reference/migration/migrate_5_2.asciidoc#L9-L16)）：

> Elasticsearch has attempted to install a system call filter since version 2.1.0. On some systems, installing this system call filter could fail. Previous versions of Elasticsearch would log a warning, but would otherwise continue executing potentially leaving the end-user unaware of this situation. Starting in Elasticsearch 5.2.0, there is now a bootstrap check for success of installing the system call filter. If you encounter an issue starting Elasticsearch due to this bootstrap check, you need to either fix your configuration so that the system call filter can be installed, or *at your own risk* disable the system call filter check.

过滤器装不上意味着这层防护缺失，而旧版本只写一行 warning，用户往往不知道。5.2 把它加进 bootstrap check 的理由就是这个：安全相关的降级必须显式暴露。

![02-SystemCallFilter](https://developer.qcloudimg.com/http-save/yehe-7348459/9f4f623d06c2776572744b03819858fe.png)

*图 2：官方文件 SystemCallFilter.java（v5.6.16 标签）。来源：GitHub elastic/elasticsearch v5.6.16 SystemCallFilter.java*

## 被拦的是什么

`SystemCallFilter` 的类注释（[SystemCallFilter.java 第 46–75 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/core/src/main/java/org/elasticsearch/bootstrap/SystemCallFilter.java#L46-L75)）写明了它做什么：装一个过滤器来阻止进程执行（`Installs a system call filter to block process execution`）。按系统分，做法不同：

| 系统 | 做法 |
|---|---|
| Linux | BPF 过滤器，拦 `execve`、`fork`、`vfork`、`execveat`，返回 `EACCES` |
| Solaris 10+ | 用 `priv_set(3C)` 去掉 `PRIV_PROC_FORK`、`PRIV_PROC_EXEC` 权限 |
| BSD 系 | 用 `setrlimit(RLIMIT_NPROC)` 限制进程创建 |
| Mac OS X Leopard+ | 装自定义 `sandbox(7)`（Seatbelt）profile |
| Windows | 也支持（注释里列在支持列表中） |

Linux 上的条件（[第 50–54 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/core/src/main/java/org/elasticsearch/bootstrap/SystemCallFilter.java#L50-L54)）：支持 amd64 和 i386，要求内核 3.5 以上，且内核编译时开了 `CONFIG_SECCOMP` 和 `CONFIG_SECCOMP_FILTER`。过滤器装的时候优先用 `seccomp(2)`（3.17+），因为它能应用到进程里已有的线程；否则退回 `prctl(2)`（3.5+），只对 ES 自己的应用线程生效。

所以"过滤器"这个名字比 "seccomp" 准确：Linux 上用 seccomp，别的系统上是别的机制，目的一致。

防护的作用是：ES 进程被攻破后（5.x 时代的脚本漏洞是常见攻击面），攻击者也难以在这个进程里起新进程。

![03-bootstrap-checks](https://developer.qcloudimg.com/http-save/yehe-7348459/fa31151674d2dc378bf3aedd429a74a4.png)

*图 3：官方文件 bootstrap-checks.asciidoc（v5.6.16 标签）。来源：GitHub elastic/elasticsearch v5.6.16 bootstrap-checks.asciidoc*

## 只改一处就够

官方 bootstrap checks 文档（[bootstrap-checks.asciidoc 第 188–199 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/docs/reference/setup/bootstrap-checks.asciidoc#L188-L199)）：

> The system call filter check ensures that if system call filters are enabled, then they were successfully installed. To pass the system call filter check you must either fix any configuration errors on your system that prevented system call filters from installing (check your logs), or *at your own risk* disable system call filters by setting `bootstrap.system_call_filter` to `false`.

源码里的条件（[BootstrapChecks.java 第 528–531 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/core/src/main/java/org/elasticsearch/bootstrap/BootstrapChecks.java#L528-L531)）：

```java
public boolean check() {
    return areSystemCallFiltersEnabled && !isSystemCallFilterInstalled();
}
```

也就是说：只有"过滤器开着"**且**"没装上"才算失败。把过滤器关掉（`bootstrap.system_call_filter: false`），`areSystemCallFiltersEnabled` 变成 false，检查直接通过。不需要另外再禁用这项检查——它是随着过滤器开关自动生效的。

失败时的消息（[第 539–542 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/core/src/main/java/org/elasticsearch/bootstrap/BootstrapChecks.java#L539-L542)）：

```text
system call filters failed to install; check the logs and fix your configuration or disable system call filters at your own risk
```

这条消息把两种处理方式都列出来了。

## 设置改名

> These are enabled by default and could be disabled via `bootstrap.seccomp`. The naming of this setting is poor since seccomp is specific to Linux but Elasticsearch attempts to install a system call filter on various operating systems. Starting in Elasticsearch 5.2.0, this setting has been renamed to `bootstrap.system_call_filter`. The previous setting is still support but will be removed in Elasticsearch 6.0.0.

（[migrate_5_2.asciidoc 第 23–28 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/docs/reference/migration/migrate_5_2.asciidoc#L23-L28)）

迁移：`bootstrap.seccomp: false` 改成 `bootstrap.system_call_filter: false`。旧名 5.x 还能用，6.0 删除，所以 5.x 期间不用急着改，但要在 6.0 之前改完。

## 装不上的常见原因

- **容器的 seccomp profile 不允许**：Docker 默认的 profile 会挡掉 ES 装过滤器所需的系统调用。这是容器化环境里最常见的一条；
- **内核太旧或未开相关编译选项**：Linux 上要求 3.5+ 且开了 `CONFIG_SECCOMP` / `CONFIG_SECCOMP_FILTER`（见上表）；
- **JNA 不可用**：ES 通过 JNA 装过滤器，JNA 不可用时 `Natives` 会打一条 warning 然后放弃（[Natives.java 第 107–112 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/core/src/main/java/org/elasticsearch/bootstrap/Natives.java#L107-L112)），这种情况过滤器没装上，5.2 起同样会触发启动检查；
- **虚拟化 / 沙箱环境拦截相关系统调用**。

按官方的说法，判断依据是启动日志（"check your logs"）。日志里会有过滤器安装失败的具体原因，比照上面的分类逐项排除。

## 静默降级比不可用更危险

这条改动的逻辑很直接：过滤器装不上时，旧版本只打一条警告就继续跑，用户可能完全不知道自己的 ES 少了一层安全保护。5.2 之后装不上就不启动。

这个取舍是对的，理由是"以为安全、实际不安全"比"起不来"糟糕得多：前者你不会去管，直到出事；后者你会立刻处理。

顺着这个思路看 5.x 的整体倾向，是把"本来就该是硬约束"的检查放进 bootstrap check（内存锁定、文件描述符、系统调用过滤器都是）。当时升级 5.x 最常见的痛苦就是节点起不来，原因往往就是这些检查，但方向是对的。

补一层：这类"静默降级"不只在安全领域出现。凡是"能跑但缺了点什么"的情况，都值得问一句——缺的这点要不要显式暴露出来。显式失败的代价是运维工作量，收益是状态可预期。

## 容器里的处理方式，按优先级

- **首选：调整容器的 seccomp profile**。自己写一份允许相关系统调用的 profile 挂进去，改动最小、不放额外权限；
- **次选：`--security-opt seccomp=unfiltered`**。省事，但等于这个容器完全不设防，只在可信环境用；
- **不推荐：放大 capability**（比如为这个目的加 `--cap-add`）。这比上面那条更危险；
- **兜底：关掉过滤器**（`bootstrap.system_call_filter: false`）。最后才考虑，并且要记录原因。

前两种之外的选项都应该附一份书面说明（为什么必须这么配、风险是什么）。这类配置一旦写进部署模板，后面没人会再问为什么。

关掉过滤器的节点要额外做网络隔离：少了一层保护，就要在别的层面补上。

## 怎么确认过滤器装上了

别靠"节点起来了"判断——5.2 之后装不上就起不来，所以这一条反而简单。真正要防的是"有人为了先跑起来把过滤器关了，后面没人发现"。这类配置不会报错，只在被攻击时才体现出差别。

做法：

1. 启动时看日志里有没有过滤器安装成功的记录；不同 OS 的措辞可能不同（前面说过，各系统实现不同），判断标准是"有没有明确的安装成功记录"，不是某个固定字符串；
2. 把这一项做成部署后的自检项：新环境部署完跑一遍确认；
3. 定期核对配置：确认 `bootstrap.system_call_filter` 没有被设成 `false`，或者明确知道哪些集群设了、原因是什么。

```sh
# 启动日志里找过滤器相关记录
journalctl -u elasticsearch --since "10 min ago" | grep -i "system call filter\|seccomp"

# 确认配置里有没有关掉
grep -rn "system_call_filter\|bootstrap.seccomp" /etc/elasticsearch/
```

## 和其它 bootstrap check 的关系

5.x 的 bootstrap check 是一组启动前置条件（堆大小、文件描述符、mmap 数量、内存锁定、onError/onOutOfMemoryError 与 fork 的冲突等）。系统调用过滤器是其中一个安全向的成员。

同一页里还有两项和过滤器相关的检查值得留意（[bootstrap-checks.asciidoc 第 201–215 行](https://github.com/elastic/elasticsearch/blob/v5.6.16/docs/reference/setup/bootstrap-checks.asciidoc#L201-L215)）：JVM 的 `OnError` 和 `OnOutOfMemoryError` 允许在致命错误或 OOM 时执行任意命令，而过滤器会阻止 fork，两者冲突时节点起不来。所以如果配了这两个选项，要么去掉它们，要么关掉过滤器——这是一组需要一起看的配置。

排查启动失败时，日志会明确指出是哪一项没过。看到 system call filter 相关，按上面的顺序排查：先看容器/内核是否允许，再决定要不要关。

## 升级 5.2 的检查清单

1. 配置里 `bootstrap.seccomp` 改成 `bootstrap.system_call_filter`；
2. 先在灰度节点启动一遍：这项检查在老内核、受限容器上最容易触发，直接全量升级可能一批节点起不来；
3. 启动了看日志确认过滤器装上（不是只看"起来了"）；
4. 容器环境优先修 seccomp profile，不要一上来就 `false`；
5. 确认 JVM 参数里没有 `OnError` / `OnOutOfMemoryError`（它们和过滤器冲突）；
6. 记录哪些集群因为环境限制关掉了过滤器，把这类节点视为需要额外网络隔离的对象。

## 在 5.6.16 上跑一遍

过滤器开关的默认值和改动方式，读一次集群设置就能看清。

![04-system-call-filter-setting](https://developer.qcloudimg.com/http-save/yehe-7348459/fa5a83166f06d6fb96cf002caba5126a.png)

*图 4：5.6.16 单节点实例的实测输出。默认 `bootstrap.system_call_filter=true`、`bootstrap.seccomp=true`；两项动态改都报 `not dynamically updateable`；对照的普通动态设置返回 `acknowledged:true`。*

```bash
curl -s 'http://localhost:9200/_cluster/settings?include_defaults=true' \
  | jq -c '{system_call_filter:.defaults.bootstrap.system_call_filter, seccomp:.defaults.bootstrap.seccomp}'
# {"system_call_filter":"true","seccomp":"true"}
curl -s -X PUT 'http://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' \
  -d '{"persistent":{"bootstrap.system_call_filter":false}}' | jq -r '.error.root_cause[0].reason'
# persistent setting [bootstrap.system_call_filter], not dynamically updateable
curl -s -X PUT 'http://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' \
  -d '{"persistent":{"bootstrap.seccomp":false}}' | jq -r '.error.root_cause[0].reason'
# persistent setting [bootstrap.seccomp], not dynamically updateable
curl -s -X PUT 'http://localhost:9200/_cluster/settings' -H 'Content-Type: application/json' \
  -d '{"transient":{"cluster.routing.allocation.enable":"all"}}' | jq -c '.acknowledged'
# true
```

图 4 坐实了两件事：5.6.16 默认开着两项过滤器；关掉它们必须在节点启动前改配置，运行中改不了。这也解释了正文说的「自担风险关掉」为什么是配置层面的动作，集群设置 API 动不了它。

边界：

* 图 4 出自 5.6.16 单节点实例，过滤器正常安装，未模拟安装失败，「装不上就拒绝启动」这条 bootstrap check 未触发验证；
* 启动日志里没有 seccomp 相关输出，安装过程无法从日志确认；
* 各系统被拦的系统调用清单仍是源码依据，未逐个验证。


## 写在最后

5.2 把系统调用过滤器从"装不上就警告"变成 bootstrap check，同时把设置名从 Linux 专有的 `seccomp` 改成通用的 `system_call_filter`。

通过条件只有一步：要么修好环境让过滤器装上，要么自担风险关掉过滤器（`system_call_filter: false`）。关掉之后检查自动通过，不需要再单独禁用这项检查。

容器化环境里最常见的原因是 seccomp profile 不允许，优先修 profile 而不是关检查。关掉的节点记下来，按"少了一层保护"来对待。

## 参考

- [migrate_5_2.asciidoc @ v5.6.16](https://github.com/elastic/elasticsearch/blob/v5.6.16/docs/reference/migration/migrate_5_2.asciidoc)

> 本文对照 Elasticsearch `v5.6.16` 标签的官方文档核对，引文逐字取自原文。「在 5.6.16 上跑一遍」里已实际读到默认 `bootstrap.system_call_filter=true`、`bootstrap.seccomp=true`，两项动态改都被 `not dynamically updateable` 拒绝，对照的普通动态设置返回 `acknowledged:true`。**"装不上就拒绝启动"**未触发验证（本机过滤器正常安装）；各系统被拦的系统调用清单仍是源码依据，未逐个验证。


5.2 把"系统调用过滤器有没有装成功"变成 bootstrap check：过滤器开着但没装上，节点拒绝启动。同时 bootstrap.seccomp 改成 bootstrap.system_call_filter（旧名在 5.x 仍可用，6.0 删除）。官方 bootstrap checks 文档对这项检查的通过条件写得很直接：要么修好让过滤器能装上，要么自担风险把过滤器关掉——一步，不是两步。本文按 v5.6.16 源码把检查的实现条件、各系统上被拦的系统调用、装不上的常见原因列出来。

考古｜ES 5.2 起 seccomp 装不上就起不来，官方叫它过滤器是有原因的

5.2 把"系统调用过滤器有没有装成功"变成 bootstrap check：过滤器开着但没装上，节点拒绝启动。

官方产研

云计算

后端

大数据

Elasticsearch 5.2系统调用过滤器升级：设置改名bootstrap.system_call_filter，过滤器未装成功节点拒绝启动。通过条件仅需修复环境或自担风险关闭过滤器，容器环境优先调整seccomp profile，关闭后需额外网络隔离并记录原因。

Elasticsearch 

代码解释

虚拟化

容器

Docker

Linux

JSON

Java

腾讯云双十一大促

bigdata-class

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

考古｜ES 5.2 起 seccomp 装不上就起不来，官方叫它过滤器是有原因的-腾讯云开发者社区-腾讯云

考古｜ES 5.2 起 seccomp 装不上就起不来，官方叫它过滤器是有原因的

考古｜ES 5.2 起 seccomp 装不上就起不来，官方叫它过滤器是有原因的

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐