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。这会导致两类典型误判：

Browser Setup (No-Root Linux)

在无 root/sudo 权限的环境（云容器、VPS、隔离主机）中安装并配置 OpenClaw 浏览器工具的 headless Chrome。适用场景：...

下载

• 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 —— 这是很多权限丢失的根本原因。