I have a wrapper script A which is calling program B. A must be invoked as root so some initial setup can happen. After that, A calls setuid() and setgid() to reduce its own privileges, for safety and security. Then, A invokes B.
The problem is that B exhibits undesirable behavior if and only if A has called setuid()/setgid() before invoking B. This does not happen when I invoke B directly as different users via sudo -u xxx -g xxx. As far as I can tell (correct me if I am wrong), the only way B could know that A has changed the user is via the issetuid() syscall (I've checked the environment variables; they match).
How can I clear this bit, so that B behaves normally? It seems that the use of issetuid() is something about keeping track of whether the process is "tainted", i.e. carries artifacts from a less privileged environment (?). But I've reduced my privileges, not elevated them! And on top of that, I've scrubbed my env vars anyway!
Beyond the very terse man page on issetuid(), I can find almost nothing about this syscall/magical program state. Can anyone lend a better understanding?
dpkg -S $(man -w issetuid). – taneli May 15 '12 at 8:28suid script securitymay help. – Xiè Jìléi May 22 '12 at 12:12issetuidsyscall. Nor is it a function in the C library. I have no idea where you found a manpage for it; neithermannor Google can. Further, every non-root process has a setuid (or similar) in its history, as init starts as root and spawns them all. – derobert Jun 13 '12 at 18:56issetuidfunction. Is it possible you meanissetugid? Your description, especially the use of the adjective tainted, comports with the description in that function's manpage, and the function it similar to what you seem to have in mind, though it also returns true if the process is setgid (even if not also setuid). – Eliah Kagan Jul 16 '12 at 23:10