kernel=2.6.11.11 In a Set-UID root executable, getresuid returns the UID of the actual user, not UID 0, and setresuid refuses to change the effective UID.
Created attachment 76213 [details] Bug demo code Use this code to demonstrate the bug. As normal user: $ gcc setresuid_bug.c As root: # chown root:root a.out # chmod +s a.out # ls -l a.out -rwsr-sr-x 1 root root 8565 Jan 4 21:38 a.out As normal user: $ id uid=500(craig) gid=500(craig) 500(craig) $ a.out 500 getresuid: ruid=500 euid=500 suid=500 setresuid(..., euid=500, ...) setresuid(0, euid=500, 0) setresuid: Operation not permitted The app has the set UID flag set -- how come none of the UIDs is 0?
Reopen if this is reproducible with latest kernel, i.e. 2.6.15
Reopened and changed bug summary to indicate kernel 2.6.15. This bug is reproducable in the 2.6.15 kernel. Sample code produces the same output as before.
I think this works for me. Is this the expected output? dsd@polyethylene ~ $ ./a.out 1000 getresuid: ruid=1000 euid=0 suid=0 setresuid(..., euid=1000, ...) setresuid(0, euid=1000, 0) getresuid: ruid=0 euid=1000 suid=0 setresuid(ruid=1000, euid=0, suid=0) Done
Hmm. That output shows it's working fine. I wonder what's different with my kernel? Maybe there's some combination of flags or patches that is messing up this function. Can you tell me where I would look in the kernel for this function?
sys_getresuid and sys_setresuid are implemented in kernel/sys.c After researching it more yourself, you should bring this up on the Linux kernel mailing list if you have not found an answer. You should also ensure that SELinux and security policy support is not built as that might be causing the problem.
Solved. It wasn't a kernel issue. It was that I specified "nosuid" for some of my mounted file systems.
