Linux权限判断依据进程的EUID而非RUID：RUID标识启动者身份，EUID决定实际访问权限；SUID机制通过临时提升EUID实现安全提权与降权。
Linux里判断一个进程能不能读文件、删目录、改配置，靠的不是“谁启动了它”，而是它的Effective UID；而Real UID只负责标记“这个人到底是谁”。两者经常一样，但关键时候会分开——这正是权限控制灵活又容易出错的地方。
Effective UID决定你“能做什么”
系统检查权限时，只看Effective UID（EUID），不看Real UID。比如打开一个文件，内核比对的是进程的EUID和文件所有者的UID、所属组、其他用户权限位。EUID为0（root）时，几乎畅通无阻；EUID是普通用户ID时，就老老实实走rwx规则。
- 普通命令如
ls或cat运行时，EUID默认等于启动它的用户Real UID - 设置了SUID位的程序（如
/usr/bin/passwd），执行时EUID自动变成该文件属主的UID（通常是root） - 程序内部可通过
seteuid()临时切换EUID，但必须满足权限约束（比如只能切回Real UID或Saved UID）
Real UID标识你“本来是谁”
Real UID（RUID）在进程诞生那一刻就固定下来，代表真正发起这个操作的用户。它不会因SUID或权限提升而改变，也不能被普通进程随意修改——只有EUID为0时才能调用setuid()去动它。
- 登录Shell的RUID就是你的账号UID，所有子进程继承该RUID
- 即使你用root权限运行了一个程序，只要没设SUID，它的RUID仍是root，EUID也是root
- RUID主要用于审计、日志记录和某些安全策略（如
sudo日志里记的就是RUID）
Saved UID是权限切换的“保险栓”
当程序带SUID位启动时，内核会把文件属主的UID同时存进Saved UID（SUID）。这个值不直接参与权限检查，但它是普通进程调用seteuid()时的“可信锚点”——EUID只能切到RUID或SUID，不能随意跳转。
- 例如普通用户执行
passwd：RUID=1001，EUID=0，SUID=0（因为文件属主是root） - 程序完成敏感操作后，可调用
seteuid(1001)降权；需要再提权时，再seteuid(0)——前提是SUID仍是0 - 没有SUID机制，普通程序就无法安全地“先提权干活，再降权防误操作”
怎么快速验证当前进程的UID状态
写个小程序或用getconf配合ps就能看清区别：
- 代码里调用
getuid()得RUID，geteuid()得EUID -
ps -o pid,ruid,euid,comm可列出所有进程的RUID/EUID（需root权限看全） - 查看文件是否带SUID：
ls -l /usr/bin/passwd，看到rwsr-xr-x中的s就表示生效
