linux中文件默认权限由umask决定：文件基准666、目录基准777，减去umask值得实际权限；例如umask 0022时文件为644、目录为755，umask 0002时文件为664、目录为775；需实测验证并排查服务级配置。
直接看新文件的默认权限，再反推 umask 是否合理——这是最准、最快的办法。
查当前 umask 值
在终端运行：
umask
输出如 0022 或 0002，就是当前会话的掩码。注意：它可能因用户、shell、登录方式（SSH vs cron）而不同。要排查漏洞，不能只看 root 或你自己的会话，还得检查关键服务用户的 umask，比如 www-data、nginx、deploy 等。
可批量检查常用服务用户的默认 umask：
- 查系统级配置：
/etc/login.defs中的UMASK行 - 查 shell 初始化文件：
/etc/profile、/etc/bash.bashrc、用户家目录下的.bashrc或.profile，找含umask的行 - 查 systemd 服务：用
systemctl show --property=UMask nginx.service查特定服务的 umask 设置
验证新建文件的实际权限
别信理论值，动手测。切换到目标用户（如 sudo -u www-data bash），然后创建测试文件和目录：
touch testfile && mkdir testdir && ls -l test*
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
观察结果：
- 若出现
-rw-rw-rw-（666）或drwxrwxrwx（777），说明 umask 是 0000 —— 危险！ - 若文件是
-rw-rw-r--（664）、目录是drwxrwxr-x（775），说明 umask 很可能是 0002 —— 组内协作常见，但需确认组成员是否可信 - 若文件是
-rw-r--r--（644）、目录是drwxr-xr-x（755），对应 umask 0022 —— 基础安全线 - 若文件是
-rw-------（600）、目录是drwx------（700），对应 umask 0077 —— 严格隔离，适合敏感环境
特别注意：Web 应用中，PHP 脚本被 web 服务器用户（如 www-data）创建时，若 umask 是 0002，生成的 .php 文件就可能是 664，其他用户可读——这违反最小权限原则。
定位权限过宽的源头配置
很多系统默认没设 umask，或只在交互式 shell 里设，而 cron、systemd、CI/CD 流水线等非交互场景会回退到内核默认（通常是 0022）。排查重点：
-
cron 任务：crontab 执行时不会加载 .bashrc，需显式写
umask 0027在脚本开头 -
PHP-FPM / Apache / Nginx 的子进程：它们的 umask 由主配置控制，例如 PHP-FPM 的
php-fpm.conf中有process.umask = 0027 -
Docker 容器：基础镜像可能未设 umask，启动时可通过
--user或 ENTRYPOINT 脚本强制设置 -
部署脚本（如 Ansible、Capistrano）：检查是否用了
copy模块却没指定mode，或shell模块执行了未设 umask 的命令
修复后验证是否生效
改完配置别急着上线，先验证：
- 重启相关服务（如
systemctl restart php7.4-fpm） - 用相同用户再次运行上一步的
touch && mkdir测试 - 对关键路径做真实模拟：比如让 Web 应用自动生成一个日志文件或缓存文件，再
ls -l看权限
记住：umask 不影响已有文件，只管“新出生”的对象。所以修复后，旧文件仍需手动收紧，比如：
find /var/www -type f -perm /002 -exec chmod o-w {} \;
这条命令去掉其他人（others）的写权限，补上 umask 没兜住的那部分。
