setcap 是非 root 用户程序执行特权操作的唯一可靠起点，必须为二进制文件显式设置对应 capability（如 cap_net_bind_service+ep），且需确保无 SUID 位、避免被 strip 破坏扩展属性；动态调用 setuid/prctl/libcap 无法绕过该前提。
setcap 是唯一靠谱的起点
想让非 root 用户运行的 C++ 程序执行需特权的操作（比如绑定 80 端口、设置系统时间），setcap 是必须走的第一步，没有替代方案。内核只在 execve() 时检查可执行文件的文件能力（file capabilities），而不是看进程当前 UID 或代码里写了什么权限逻辑。所以你在 C++ 里调用 setuid()、prctl() 或 libcap 函数，都无法绕过这个前提：目标二进制本身没被赋予对应 capability，一切动态操作都无效。
常见错误是以为“先 fork + setcap 进程 + execl”能生效——不行。execl() 启动的新程序，其初始 capability 集合完全由该新程序文件自身的 setcap 设置决定，和父进程无关（除非父进程显式传递 ambient 或 inheritable 能力，但普通 execl() 不触发继承）。
正确做法只有这一条路径：
- 用
sudo setcap cap_net_bind_service+ep /path/to/your_program给编译好的二进制加能力 - 确保该二进制不带 SUID 位（
chmod u-s），否则 capability 会被内核忽略 - 用普通用户直接运行它，无需
sudo或su
cap_sys_time 这类能力需要特别注意继承链
像 CAP_SYS_TIME（用于 settimeofday()）这种能力，光靠 setcap cap_sys_time+ep 不一定够。因为内核要求：若进程要执行该系统调用，其 CapEff 中必须包含该能力，而 CapEff 默认只从文件的 permitted 集中取交集，且受 bounding set 限制。
你写 C++ 程序调用 settimeofday() 时失败，报错 Operation not permitted，大概率是因为：
- 二进制确实设置了
cap_sys_time+ep，但运行时CapEff为空（比如被 systemd 或容器 runtime 清空了） - 父进程（如 shell）没把
cap_sys_time放进自己的CapInh，导致 exec 后无法继承到CapEff - 系统启用了 securebits（如
SECBIT_NO_CAP_AMBIENT_RAISE），阻止 ambient 能力提升
验证方式：./your_program 启动后立即在另一终端执行 cat /proc/$(pidof your_program)/status | grep Cap，重点看 CapEff 是否非零。如果为 0，说明能力没真正激活，得回退检查 setcap 命令是否执行成功、文件是否被 strip 或重打包破坏了扩展属性。
fork + setuid + execl 组合必须满足三个条件
如果你的 C++ 主程序需要 fork 子进程、切换 UID、再 execl() 执行另一个特权程序（比如用普通用户启动一个能改时间的 setTime.bin），那整个链条有硬性约束：
- 子进程必须在
execl()前调用prctl(PR_SET_KEEPCAPS, 1)，否则setuid()会清空所有 capability -
setuid()必须在prctl()之后、execl()之前调用，且目标 UID 必须是普通用户（不能是 0） - 被
execl()的目标二进制（如setTime.bin）本身必须已用setcap cap_sys_time+ep授权，且不能是脚本（脚本解释器如/bin/sh会接管能力，导致丢失）
漏掉任意一条，子进程都会以无任何 capability 的状态执行目标程序，settimeofday() 直接失败。这不是 bug，是 capability 模型的设计使然。
容器或 systemd service 下 capability 更容易失效
在 Docker 或 systemd 里跑 C++ 程序时，setcap 很可能白做。Docker 默认丢弃所有 capability（除了少数几个如 CAP_CHOWN），即使你在镜像里提前 setcap，运行时仍需显式加 --cap-add=SYS_TIME；systemd 则默认启用 NoNewPrivileges=true，会直接屏蔽文件 capability 的生效。
排查方法：
- Docker：确认是否用了
--cap-add=SYS_TIME，且没同时用--privileged（二者冲突） - systemd：检查 service 文件里有没有
NoNewPrivileges=true或CapabilityBoundingSet=限制；如有，得显式放开，例如CapabilityBoundingSet=CAP_SYS_TIME并配AmbientCapabilities=CAP_SYS_TIME - 不管哪种环境，最终都要进容器或服务进程里执行
capsh --print看实际生效的能力集
最常被忽略的一点：capability 不是“开了就永远有效”，它活在进程生命周期里，且每一步 exec、setuid、prctl 都可能重置它。别信“设一次，管全程”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
