我通过在终端上使用以下 cmd 添加了该功能(在嵌入式文件中设置 CAP_SETUID 的替代方法)。已验证 setuid/seteuid 是否正常工作。
setcap cap_sys_admin,cap_setuid+ep /usr/bin/<processname>
现在我想将我的进程设置为root权限-->sync()-->设置为原始权限--->做一些工作-->再次设置为root--->sync()
在使用 setuid() 时,我发现我们只能在一个启动周期内将进程设置为 root 一次。不过可以通过seteuid()来完成,我也尝试过,仍然无法达到预期的结果。
你能建议我缺少什么或正在做的工作吗?
int id = geteuid();
int r0= seteuid(0); // This will raise process to root mode
sync(); //process can perform operation as root user
seteuid(id); //set process as non root user
第一次 r0 为 0[成功],第二次 r0 为 -1[seteuid(0) 中的错误]。 (在同一启动周期)提前致谢。
答案1
不幸的是我在内核文档中找不到明确的解释,只是一个提示man 2 setuid
:
如果用户是 root 或程序是 set-user-ID-root,则必须特别注意:setuid() 检查调用者的有效用户 ID,如果是超级用户,则所有与进程相关的用户 ID 都设置为uid。发生这种情况后,程序就不可能重新获得root权限。
通过添加功能来允许此断言无效是没有多大意义的。为什么 FSCAP 程序比 SUID root 程序更强大?
如果这个答案上SO是正确的,那么你的问题可以解释为:
默认情况下,功能集在 UID 转换期间丢失
setuid()
和的不同行为seteuid()
是有意为之的,涵盖了不同的场景(不允许(不允许)切换回 root)。