你用 setsebool -P 设好了某个 SELinux 布尔值，服务也恢复正常了。过几天想复查一下确认它还在生效，于是跑到 /etc/selinux/ 下，对策略文件 grep 那个布尔值的名字——结果什么都没有。你开始怀疑：是不是根本没设成功？是不是 -P 没生效？是不是重启后被重置了？
现象
- 之前明明执行过
setsebool -P <布尔值> on； - 在策略文件目录里（如
/etc/selinux/targeted/policy/）grep该名字，搜不到任何结果； - 于是误判成"设置没生效 / 根本没落盘"。
根因
根因是 SELinux 的布尔值会被编译进二进制策略文件，它不是文本，所以用文本 grep 自然找不到。
SELinux 的策略以两种形态存在：
- 源策略：人类可读的文本（
.te、.if、.fc等），但那是编译前的形态，通常在开发/构建时用； - 二进制策略：最终加载进内核的形态，存在
/etc/selinux/<类型>/policy/policy.XX这类文件里，是编译产物。
setsebool -P 的 -P 做的事，是把改动写进二进制策略（准确说是把修改持久化到内核可加载的策略存储里），而不是去改某个文本文件。你 grep 的正是那个二进制文件——里面是一堆二进制字节，布尔值的名字不以可直接搜索的明文形式存在（或者被压缩、编码了），所以 grep 搜不到。
这里的认知误区是："找不到"不等于"不存在"。 你在用错误的工具查一个用错误形态存储的值。二进制文件用文本搜索，本来就是缘木求鱼。
需要强调一点：改动本身是持久、有效的。 -P 已经把设置写进策略，重启后依然生效；搜不到纯粹是查询方式不对。
解决
用正确的工具查询 SELinux 布尔值，而不是对策略文件 grep。
查单个布尔值的当前值：
getsebool httpd_can_network_connect
# 输出：httpd_can_network_connect --> on
列出所有布尔值：
getsebool -a
只看本地改动过的布尔值（最推荐，能直接回答"我改了什么"）：
sudo semanage boolean -l -C
-C 表示只看"本地自定义（customized）"的项，也就是被你手动改过、与默认值不同的那些。它会带出当前值和默认值，一眼就能确认你的改动在不在：
httpd_can_network_connect (on, off) Allow httpd to network connect
# ↑当前值 ↑默认值
再补充一点：布尔值的定义（策略里说了哪些布尔值存在、含义是什么）也在这套工具里查，而不是文本文件：
sudo semanage boolean -l # 全部布尔值及用途说明
这样查出来的信息，比你 grep 文本要准确、也完整得多。
延伸与预防
这条坑的通用教训是：找不到 ≠ 不存在，先确认你在用正确的工具查。
可复用的原则：
- 别对二进制产物做文本搜索。 SELinux 策略、数据库文件、编译后的二进制、某些缓存文件，都是这个道理。想确认它们的状态，要用它们配套的查询工具（
getsebool、semanage、sqlite3、xxd等），而不是grep。 - 区分"配置源"和"运行态"。 很多系统里，"我改的配置"会被编译/转换/合并后才生效。要确认最终生效值，得查运行态或编译后的状态，而不是你手里那份源文件。
- 把"我改过的项"单独列出来。
-C这类"只看自定义项"的参数非常实用——它能直接回答"相对于默认值，我动了什么"，比全量列表更有价值。
一句话：查状态要用对的工具——二进制的东西，用能读懂它的工具去读。