selinux 不干扰 umask，其权限异常实为访问拦截：文件创建权限正常（如 644），但因上下文不匹配或策略限制导致后续读写被拒；排查应查 audit 日志、用 audit2why 分析、修复上下文或布尔值。

SELinux 不会修改 umask，也不会直接干扰文件创建时的权限掩码。所谓“SELinux 引起的文件权限掩码异常”，其实是误判——真正被拦住的不是 umask 生效过程，而是进程后续对刚创建文件的访问行为（比如写入、读取、执行），而这些行为因 SELinux 上下文不匹配或策略限制被拒绝，让人误以为“文件权限生成错了”。

先确认是不是真和 umask 有关

umask 是内核级进程属性，由 shell 继承并传给子进程，SELinux 完全不参与它的计算或设置。排查第一步必须剥离干扰：

• 用 umask 命令查看当前会话实际值（如 0022）
• 手动创建测试文件：touch /tmp/testfile && ls -l /tmp/testfile，观察权限是否符合预期（如 644）
• 如果新建文件权限本身就不对（比如期望 644 却得到 600），问题一定出在 shell 配置（~/.bashrc、/etc/profile）或应用自身调用了 umask() 系统调用，和 SELinux 无关

常见误判场景：文件创建成功，但立刻无法访问

这是最典型的“像 umask 问题，实为 SELinux 拦截”：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• Web 应用往 /var/www/upload 写文件，touch 成功，但 PHP 脚本读不到，报 Permission denied
• MySQL 启动后在 /var/lib/mysql 创建了新表文件，但客户端查询时报 Can't open file
• 日志轮转工具生成新日志，但服务进程无法追加写入

这些都不是 umask 没设好，而是新文件继承了父目录的错误 SELinux 上下文（比如父目录是 httpd_sys_content_t，但写入进程是 httpd_t，策略不允许它写该类型），或者进程本身缺少对应布尔值（如 httpd_can_network_connect_db）。

精准定位 SELinux 拦截点

不要猜，直接查审计日志：

• 运行 ausearch -m avc -ts recent | grep -E "(httpd|mysqld|your_process_name)"
• 重点看 scontext（进程上下文）和 tcontext（目标文件上下文）是否匹配策略允许的动作
• 用 audit2why 解读：ausearch -m avc -c httpd | audit2why，它会明确告诉你缺哪条规则，并建议执行 restorecon 或 setsebool
• 检查文件当前上下文：ls -Z /path/to/file；对比进程类型：ps -eZ | grep httpd

修复三类高频上下文错配

90% 的这类“权限异常”都落在以下情形：

• 目录上下文错误：自定义路径（如 /data/web）未打标签，导致新文件继承 default_t，而进程类型（如 httpd_t）无权访问 → 用 semanage fcontext -a -t httpd_sys_content_t "/data/web(/.*)?" 加永久规则，再 restorecon -Rv /data/web
• 进程类型与操作不匹配：比如 PHP-FPM 运行在 php_fpm_t，但需要访问数据库 socket，而 socket 标签是 mysqld_var_run_t → 启用布尔值：setsebool -P php_fpm_can_network_connect_db 1
• 临时文件目录无写权限：/tmp 或 /var/tmp 下的文件被写入但进程无法读取 → 检查是否被标记为 tmp_t，而进程类型未被授权 → 可改用 /var/run/php-fpm 等专用路径，或为 tmp 目录添加合适上下文