linux权限异常需逐层检查路径各目录的x/r/w权限，用namei -l查看中断点，结合id确认用户组身份，注意acl、特殊权限位、文件隐藏属性及selinux/apparmor策略影响。
Linux权限异常通常不是单一环节出问题，而是多个权限节点串联失效导致。排查时需从访问路径逐层向上验证：目标文件本身、其父目录、再上层目录……直到根目录，每级都必须有对应执行（x）权限才能进入，读（r）权限才能列出内容，写（w）权限才能修改或删除。
检查目标路径每一级的目录权限
用户无法进入 /home/alice/project/config.txt，不能只看 config.txt 的权限，而要依次检查：
- / —— 必须有 x 权限（通常都有）
- /home —— 当前用户需有 x 权限才能进入 home 目录
- /home/alice —— 若该目录权限为 drwx------（即700），且用户不是 alice 或 root，则无法进入，后续所有子项均不可达
- /home/alice/project —— 同样需 x 权限才能 cd 进入，r 权限才能 ls 查看
- config.txt —— 最终文件权限决定能否读/写/执行
用 namei -l /home/alice/project/config.txt 一条命令即可显示完整路径各段的属主、属组和权限，自动标出中断点。
确认用户真实身份与所属组
使用 id 查看当前会话的实际 UID、GID 和补充组列表。注意：
- 新加入的用户组不会在已有 shell 中生效，需重新登录或用 newgrp 切换
- sudo 切换用户后，组信息可能未同步（如 sudo -u alice bash 不等同于直接登录 alice）
- systemd 服务中运行的进程，其组成员关系取决于服务定义时的上下文，未必继承登录用户的组
留意特殊权限位与访问控制列表（ACL）
普通 ls -l 看不到 ACL 和某些扩展属性，但它们会覆盖基础权限：
- 用 getfacl /path 检查是否存在 user:xxx、group:yyy 或 mask 影响实际生效权限
- 关注 setuid（u+s）、setgid（g+s）、sticky bit（o+t）是否意外启用，例如 /tmp 若丢失 sticky bit，可能导致普通用户删掉他人文件
- ext4 文件系统上，lsattr 可查看不可修改（immutable, i）、仅追加（a）等隐藏属性，这些会使 chmod/chown 失效
验证 SELinux 或 AppArmor 是否介入
在 CentOS/RHEL 或 Ubuntu 启用强制访问控制的系统中，即使 DAC 权限全开，策略仍可拒绝访问：
- 用 sestatus 查看 SELinux 是否启用；aa-status 查看 AppArmor 状态
- 尝试临时设为 permissive 模式（setenforce 0 或 sudo aa-complain /path），观察问题是否消失
- 检查 /var/log/audit/audit.log（SELinux）或 /var/log/syslog（AppArmor）中的 avc denied 记录，定位具体被拒的操作和上下文
