直接检查 geteuid() == 0 即可判断是否以 root 身份运行，因 root 的有效用户 ID 恒为 0；geteuid() 返回当前进程实际权限级别，比 getuid() 或用户名匹配更可靠、高效且符合内核权限本质。
如何用 geteuid() 判断当前进程是否以 root 身份运行
在 Linux/macOS 上，geteuid() 是最直接、开销最小的判断方式：它返回当前进程的**有效用户 ID（EUID）**。root 用户的 UID 恒为 0，所以只需检查 geteuid() == 0 即可。
注意：不要用 getuid()（真实 UID），它在 setuid 程序中可能仍是启动用户的 ID；而 EUID 才反映当前实际权限级别。
示例代码：
#include <unistd.h>
#include <stdio.h>
int main() {
if (geteuid() == 0) {
printf("running as root\n");
} else {
printf("not root (euid = %d)\n", geteuid());
}
return 0;
}
- 必须包含
<unistd.h></unistd.h>，否则编译报错：‘geteuid’ was not declared in this scope - 链接时无需额外库，
geteuid()是 POSIX 标准函数，glibc/ musl 都支持 - 在容器中运行时，若容器以
--user=0或未指定 user 启动，geteuid()仍返回 0；但若被--user=1001限制，则返回非零值
为什么 geteuid() == 0 比检查用户名更可靠
有人会想用 getpwuid(geteuid()) 取用户名再 strcmp("root")，这不仅多一次系统调用，还引入了两个风险：
立即学习“C++免费学习笔记（深入）”；
- /etc/passwd 被篡改或挂载为只读时，
getpwuid()可能返回NULL，导致段错误 - 某些嵌入式或容器环境压根没有
root这个用户名（比如只保留 UID 0 条目但注释掉 name 字段），但 UID 0 的权限依然存在 - SELinux 或 user namespaces 下，用户名和权限是解耦的，只看 UID/EUID 才反映真实能力
权限的本质是内核对 UID 的检查，不是字符串匹配。
在 C++ 中调用 geteuid() 的常见编译与链接问题
使用 g++ 编译时，若忘记定义 _GNU_SOURCE 或 _POSIX_C_SOURCE，可能触发隐式声明警告甚至失败：
- Clang/GCC 12+ 默认启用 -Werror=implicit-function-declaration，未声明就用
geteuid()直接编译失败 - 解决方法：在源文件最顶部加
#define _GNU_SOURCE（Linux）或#define _POSIX_C_SOURCE 200809L（macOS / 通用 POSIX） - 不推荐用
-D_GNU_SOURCE命令行参数——它会影响整个编译单元，可能意外启用其他 GNU 扩展导致跨平台问题 - 如果项目用 CMake，应在 target_compile_definitions 中显式添加，而非全局 add_definitions
setuid 程序或 capabilities 场景下，geteuid() 还管用吗
管用，而且正是它的设计场景。
例如一个 chmod +s 的二进制文件，由普通用户执行时：
-
getuid()返回普通用户 UID（如 1001） -
geteuid()返回文件所有者的 UID（如 0），即获得了临时 root 权限
同理，用 setcap cap_net_bind_service+ep ./server 赋予绑定低端口能力后，geteuid() 仍是非零，但程序确实能 bind(80) —— 这说明 geteuid() == 0 是“是否为 root”的充分条件，但不是必要条件；不过绝大多数需要 root 的操作（如 mount、chown、写 /sys/class/leds）仍强依赖 UID 0。
如果你真要细粒度检测某项 capability，得用 cap_get_proc() + cap_get_flag()，但那是另一套复杂逻辑了。
