geteuid()返回0表示当前进程拥有root级权限，可写/etc、绑定1024以下端口等；判断特权应基于有效uid/gid而非真实uid，需配合getegid()检查组权限，头文件包含和。
Linux下用geteuid()和getegid()判断有效UID/GID
在Linux系统中，C++程序本身不直接提供“特权等级”这个抽象概念，实际要查的是进程的有效用户ID（EUID）和有效组ID（EGID）。普通用户进程的geteuid()返回非零值，而root进程返回0——这才是判断是否拥有管理员权限的可靠依据。
注意：不能只看getuid()（真实UID），因为setuid程序可能以普通用户启动但以root身份运行；真正起作用的是geteuid()。
-
geteuid()返回0→ 当前进程拥有root级权限（可写/etc、绑定1024以下端口等） -
getegid()常配合使用，某些场景需同时检查组权限（如docker组、sudo组） - 头文件必须包含
<unistd.h></unistd.h>和<sys></sys> - 示例代码片段：
#include <unistd.h> #include <sys> #include <iostream> int main() { if (geteuid() == 0) { std::cout </iostream></sys></unistd.h>
Windows上用CheckTokenMembership()验证Administrator组成员身份
Windows没有UID概念，而是靠访问令牌（access token）和SID（安全标识符）判断权限。最稳妥的方式是检查当前令牌是否属于BUILTIN\Administrators组，而不是简单比对用户名或调用IsUserAnAdmin()（该函数已被标记为过时且行为不可靠）。
关键点在于：必须先获取进程的访问令牌，再用CheckTokenMembership()查指定SID，且需启用SE_SECURITY_NAME特权才能获取完整令牌（否则可能漏判）。
- 需要链接
Advapi32.lib - 调用
OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY, &hToken)获取令牌 - 用
AllocateAndInitializeSid()构造Administrators组的SID -
CheckTokenMembership(NULL, administrators_sid, &is_member)返回非零即为管理员 - 不要依赖
GetUserName()或硬编码用户名，域环境和重命名后会失效
跨平台封装建议：避免宏定义硬分叉
直接写#ifdef _WIN32 / #else容易导致逻辑割裂、测试遗漏。更稳健的做法是定义统一接口，把平台差异收到底层实现里：
- 声明一个内联函数
bool is_privileged()，头文件不暴露平台细节 - Linux实现调用
geteuid() == 0，Windows实现走CheckTokenMembership流程 - 若需细粒度控制（如只要求网络绑定权限），应单独封装
can_bind_to_low_port()而非笼统叫“特权等级” - 静态链接时注意Windows版需确保
Advapi32.lib被正确引入，否则链接失败报LNK2019: unresolved external symbol CheckTokenMembership
常见误判场景和权限边界陷阱
很多开发者以为getuid() == 0或IsUserAnAdmin()返回true就万事大吉，结果在容器、systemd服务或sudo -u环境下出错。
- Docker容器中
geteuid()可能是0，但没挂载/dev或没加--cap-add仍无法操作硬件设备 - systemd服务默认以
RestrictSUIDSGID=true运行，即使euid=0也无法执行setuid二进制 - Linux capability机制下，进程可能只有
CAP_NET_BIND_SERVICE而无CAP_SYS_ADMIN，此时geteuid() != 0但能绑定80端口 - macOS用
getuid()和geteuid()同样适用，但部分沙盒进程即使euid=0也会被sandboxd拦截系统调用
真正决定“能做什么”的从来不是某个数字，而是当前进程实际持有的capability或token权限集。查geteuid()只是最快的一道过滤，后面总得跟具体操作的errno兜底。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
