linux权限问题需综合排查：先查基础rwx权限，再验selinux/apparmor上下文、umask设置、setgid目录、acl规则及多机制叠加影响，避免单点误判。
Linux 文件权限误配导致服务无法读取配置
服务启动失败，日志里反复出现 Permission denied，但文件明明存在——八成是权限或上下文没对。Linux 不只看 ls -l 显示的 rwx，还看 SELinux 上下文（RHEL/CentOS/Fedora）或 AppArmor（Ubuntu/Debian）是否允许该进程访问。
实操建议：
- 先确认基础权限：
ls -l /etc/myapp/config.yaml，确保运行服务的用户（如myapp）有读权限；若属主不是该用户，至少要有 group 或 other 的r - 检查 SELinux：运行
ls -Z /etc/myapp/config.yaml，对比服务进程上下文（ps -eZ | grep myapp），不匹配就用chcon -t etc_t /etc/myapp/config.yaml临时修复（生产环境应通过策略模块固化） - AppArmor 用户执行
aa-status看是否拦截，再查/var/log/audit/audit.log或dmesg中的avc: denied记录 - 别直接
chmod 777配置文件——这会绕过所有管控，且 systemd 服务默认拒绝加载 world-writable 配置
umask 设置不当引发协作目录权限混乱
团队共用 /srv/project，新人创建的文件其他人改不了，老手建的目录却没人能进——问题常出在 umask 值没统一，尤其当用户登录 shell、systemd 服务、cron 任务各自走不同初始化路径时。
实操建议：
- 查当前生效值：
umask（显示八进制）或umask -S（符号形式）；注意 bash 和 sh 行为略有差异 - 用户级修正：在
~/.bashrc或~/.profile末尾加umask 002（让组写生效），但需登出重进才对新 shell 生效 - 服务级修正：systemd 服务需在 unit 文件中设
UMask=0002（注意是六位八进制，非三位），否则即使用户 umask 正确，服务仍按 0022 创建文件 - 共享目录务必配合
setgid：chmod g+s /srv/project，这样新文件自动继承父目录所属组，避免手动 chgrp
find + chmod 批量修权时递归范围失控
find /data -type f -exec chmod 644 {} \; 执行完发现数据库文件被改成只读，备份脚本跑不起来了——因为 find 默认遍历所有子目录，没加 -maxdepth 1 或路径过滤，容易误伤。
实操建议：
- 永远先用
-print预览：find /data -type f -name "*.conf" -print，确认路径和文件名模式无误再换-exec - 限制深度：
find /data -maxdepth 2 -type f -name "*.log" -mtime +30 -exec chmod 644 {} \;，避免钻进/data/db/这类敏感子树 - 慎用
chmod -R：它不区分文件/目录，chmod -R 644 /dir会让所有子目录也变成 644（失去执行位），后续cd都失败 - 目录和文件权限要分开处理：
find /data -type d -exec chmod 755 {} \; && find /data -type f -exec chmod 644 {} \;
ACL 细粒度授权后 ls 输出变复杂，运维人员看不懂
给审计员加了 setfacl -m u:auditor:r /var/log/app.log，结果 ls -l 末尾多了个 +，但没人知道这意味着什么，更不敢动——ACL 不是黑魔法，只是扩展了传统权限模型。
实操建议：
-
+只表示该文件/目录启用了 ACL，不影响原有权限逻辑；用getfacl /var/log/app.log才能看到完整规则 - ACL 权限优先级高于传统组权限，但低于 owner 权限；如果用户同时是 owner 和 ACL 指定用户，以 owner 规则为准
- 删除某条 ACL：
setfacl -x u:auditor /var/log/app.log；清空所有扩展 ACL：setfacl -b /var/log/app.log - 复制带 ACL 的文件要用
cp -a（保留属性），普通cp会丢掉 ACL；rsync 需加-a或显式--acls
真正麻烦的从来不是单点权限设置，而是多个机制叠加后的隐式行为：SELinux 上下文 + systemd UMask + 目录 setgid + 用户 umask + ACL —— 其中任意一个环节配置偏移，都可能让“看起来应该能读”的文件实际打不开。调试时别只盯一个地方。
