linux进程权限由ruid和euid协同决定：ruid标识“谁启动了进程”，不可变，用于审计；euid决定“当前能做什么”，是内核权限检查的依据，可临时提升（如setuid程序）或降权。
Linux进程的权限不是由一个ID决定的，而是由多个身份标识协同作用。真正决定“谁启动了它”的是RUID（真实用户ID），而决定“它此刻能做什么”的是EUID（有效用户ID）。混淆这两者，是排查权限问题时最常见的根源。
UID、EUID、GID、EGID各司何职
每个进程在内核中维护四组基础身份：
- RUID（Real UID）：进程创建时继承自父进程，固定不变，标识“谁真正执行了这个程序”。审计日志、资源配额统计都依赖它。
- EUID（Effective UID）：内核做权限检查时实际使用的ID，比如打开文件、绑定端口、读写/proc都看它。普通程序默认等于RUID；setuid程序（如passwd）或sudo启动的进程，EUID会临时提升为root（0）。
- RGID（Real GID）与 EGID（Effective GID）：组维度的对应关系，作用逻辑一致——RGID记录原始组身份，EGID用于当前权限判定。
为什么ps -ef第一列不可靠
执行ps -ef看到的UID列，其实是EUID，不是RUID。这会导致两类典型误判：
- nginx主进程由root启动，工作进程降权为www-data：ps -ef显示UID=0，但实际服务以www-data身份运行，网络连接、文件访问权限都受EGID/www-data约束。
- 用sudo执行脚本后，ps -u $USER查不到该进程：因为EUID已变为root，而
ps -u只按EUID匹配，不查RUID。
准确查看与过滤进程身份的方法
要获得真实、完整的进程身份视图，必须显式使用ps -o：
- 一次性查看全部ID：
ps -eo pid,comm,ruid,euid,suid,rgid,egid,sgid --sort=-pid | head -15 - 按真实启动者过滤（例如查alice启动的所有进程）：
ps -eo pid,comm,ruid | awk '$3 == 1001'（1001为alice的UID） - 最底层验证方式（绕过ps缓存，直读内核）：
grep -l "Uid:.*1001" /proc/[0-9]*/status 2>/dev/null | cut -d/ -f3
权限异常的常见诱因
进程行为与预期不符，往往不是配置错了，而是没理清ID切换逻辑：
- 普通用户执行setuid程序（如/usr/bin/passwd）：RUID=1001，EUID=0，SUID=0 —— 它能改/etc/shadow，但仍是alice发起的进程。
- 服务进程启动后调用seteuid()降权：EUID从0变回RUID，但SUID仍保留root值，后续可随时恢复权限。
- exec新程序时，若目标文件无setuid位，SUID会被重置为新程序的EUID —— 这是很多权限丢失的根本原因。
