SELinux拦截数据库读写时，先用getenforce和setenforce 0验证是否为根因；再通过ausearch -m avc -c mysqld定位拒绝点；最后用semanage fcontext+restorecon修复上下文或setsebool启用对应布尔值。
遇到数据库启动失败、连接后报 Can't open file 或 Permission denied，日志里反复出现 EACCES，但 ls -l 显示权限正常——这大概率是 SELinux 在拦截，而不是文件权限本身的问题。
确认 SELinux 是否正在生效并导致拦截
先别改配置，快速验证是否为根因：
- 运行
getenforce：若输出 Enforcing，说明策略已启用 - 临时切到宽容模式：
sudo setenforce 0 - 立即重启数据库：
sudo systemctl restart mysqld（或postgresql等对应服务） - 若此时能正常启动、读写数据，基本锁定 SELinux 是问题源头
- 验证完立刻切回：
sudo setenforce 1，避免审计日志缺失
查审计日志，定位具体被拒动作
拒绝记录不会出现在 MySQL 日志或 journalctl -u mysqld 中，必须查 SELinux 审计日志：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 查最近的 AVC 拒绝：
sudo ausearch -m avc -ts recent | grep mysqld - 按进程名精准过滤：
sudo ausearch -m avc -c mysqld - 用
audit2why解读原因：sudo ausearch -m avc -c mysqld | audit2why—— 它会指出缺哪条allow规则，并建议执行restorecon或setsebool - 生成可读报告（需安装
setroubleshoot）：sudo sealert -a /var/log/audit/audit.log
修复三类典型上下文错配
90% 的数据库 SELinux 故障集中在以下场景：
-
数据目录标签错误：比如把 MySQL 数据库移到
/data/mysql，但该路径默认是default_t或var_t，而mysqld_t进程只被允许访问mysqld_db_t
→ 查当前标签：ls -Zd /data/mysql
→ 修复：sudo semanage fcontext -a -t mysqld_db_t "/data/mysql(/.*)?"，再执行sudo restorecon -Rv /data/mysql -
套接字或日志文件标签异常：如
/var/lib/mysql/mysql.sock或/var/log/mysqld.log被手动移动或新建，继承了错误上下文
→ 查标签：ls -Z /var/lib/mysql/mysql.sock /var/log/mysqld.log
→ 修复：sudo restorecon -v /var/lib/mysql/mysql.sock /var/log/mysqld.log，或批量恢复整个目录 -
关键布尔值未开启：例如主从复制需网络连接、使用外部认证模块等
→ 查可用布尔值：getsebool -a | grep mysql
→ 启用对应项：sudo setsebool -P mysqld_connect_network on（-P表示永久生效）
不推荐但可应急的操作
以下方法仅用于快速验证或临时恢复，**不可长期使用**：
-
sudo setenforce 0：临时禁用强制模式（重启后失效） -
sudo chcon -t mysqld_db_t /path/to/dir：临时修改上下文（重启或restorecon后可能被覆盖） - 彻底关闭 SELinux（
/etc/selinux/config中设为disabled）：削弱系统安全基线，生产环境应避免
