Linux进程权限异常源于真实UID/GID、有效UID/GID、保存UID/GID及文件能力间关系混乱；真实ID标识启动者，有效ID用于权限判定，保存UID支持权限切换，capabilities则提供细粒度权限控制。
Linux进程权限异常，本质是进程实际运行时的权限与预期不符，常见表现为：本该有权限的操作被拒绝（如无法读写文件），或本不该有的权限却能执行敏感操作（如提权）。核心原因在于没有理清Linux进程权限模型中“真实UID/GID”、“有效UID/GID”、“保存的设置UID/GID”以及“文件能力（capabilities）”之间的协作与优先级关系。
真实UID/GID 与 有效UID/GID 的分工
每个进程在内核中维护两组标识：真实UID/GID（ruid/rgid）和有效UID/GID（euid/egid）。真实ID反映进程启动者的身份（通常不可变），而有效ID才是内核做权限判断时真正使用的依据。例如普通用户执行 sudo 或设置了 setuid 位的程序（如 /usr/bin/passwd），其 euid 会临时变为 root，从而获得相应权限；但 ruid 仍为原用户，便于审计和部分策略识别。
- 调用 setuid(0) 成功的前提是当前 euid == 0（即已有 root 权限），否则失败
- 普通进程默认 ruid == euid；setuid 程序启动后，ruid 是用户、euid 是 root
- 系统调用如 access() 检查的是 euid/egid，不是 ruid/rgid
保存的设置UID/GID（Saved UID/GID）的作用
当进程通过 setuid 程序切换了 euid 后，内核会把原来的 euid 保存到“保存的设置UID”中（saved UID）。这个值允许进程在 root 权限和普通权限之间来回切换，避免长期持有高权限带来的风险。比如 passwd 在验证密码阶段需要 root 权限修改 /etc/shadow，但校验新密码强度时可降权运行以减少攻击面。
- 调用 seteuid(ruid) 可临时放弃 root 权限；再调用 seteuid(suid) 即可恢复（前提是 suid 未被清空）
- exec 执行新程序时，若新程序没有 setuid 位，saved UID 会被重置为新程序的 euid
- 使用 getresuid(&ruid, &euid, &suid) 可查看三者当前值
文件能力（Capabilities）正在替代传统 setuid
现代 Linux 发行版逐步限制甚至禁用全局 setuid root 程序，转而使用细粒度的 capabilities。例如 ping 不再依赖 setuid root，而是通过 cap_net_raw+ep 获得发送原始网络包的权限。这大幅缩小了权限暴露面——进程不再拥有全部 root 权力，仅保留完成任务所必需的能力。
- 用 getcap /bin/ping 查看程序绑定的能力；setcap cap_net_raw+ep /path/to/binary 可添加
- 能力分三种：effective（当前生效）、permitted（可被激活）、inheritable（可被子进程继承）
- 进程 exec 新程序时，只有 permitted & inheritable 都存在的能力，才可能传递给子进程
排查权限异常的实用步骤
遇到“Permission denied”或意外提权，不要只看 ls -l，要结合运行时状态分析：
- 用 ps -o pid,euid,ruid,suid,comm -p $PID 快速查看目标进程的 UID 状态
- 检查关键文件是否被 file capabilities 替代了 setuid：运行 getcap $(readlink -f $(which command))
- 确认 SELinux/AppArmor 是否介入：ausearch -m avc -ts recent | grep $PID（SELinux）或 dmesg | grep audit（AppArmor）
- 用 strace -e trace=stat,open,chmod,chown -p $PID 观察具体哪次系统调用因权限失败
