Re: Root running Informix utilities via su -c

Art S. Kagel wrote: > On Mon, 20 Oct 2003 09:56:24 -0400, Red Valsen wrote: > > Su only forks once which leaves the real user id accessible. But the SETUID > bit causes the shell to perform a fork also after changing the userid which > now, along with the fork performed by the 'su informix', makes for two forks as > 'informix' which obliterates the original real userid. That's how it's done in > servers that need to run as a particular user with their real and effective > userids changed - fork twice after changing user ids. Dear Art, Are you sure? The purpose of the 'su' command is to set both the real and effective user ID of the process. I'm pretty sure it also removes the saved UID too - I'd take that under advisement. And su doesn't fork - it exec's! At USENIX 2002, Chen Wagner and Dean presented a paper called "Setuid Demystified" which described the behaviour of the various setuid() variant system calls on different platforms. You can find it online at http://www.cs.berkeley.edu/~daw/papers/setuid-usenix02.pdf (Google on the title and feeling lucky). Now, when the shell is run by 'su', it has real and effective UID of informix (su informix -c "something..."). If that something is a SUID informix shell script, one of a few things happens - slightly dependent on your Unix platform. Most likely, the SUID property is ignored. Failing that, the kernel notes that the script is SUID informix and carefully changes the effective UID from informix to informix. However, since the script didn't seem to have a #!/bin/sh at the top, I'd lay odds that the SUID properties were ignored. The shell might notice that the command was simply 'commandfile' and read the file itself, or it might fork and the child might read the file and execute the contents (while the parent waits for the child to exit so it can exit too). I don't recognize the double fork stuff as an idiom that works with UID setting issues. It might be relevant to daemon processes wishing to ensure they are not affected by the death of the shell that invoked them - but that's not done like that for anything to do with [RES]UID values. >>This dead horse has had the flesh flayed from its bones years ago, but I >>discovered a new twist -- which purportedly didn't work. [...see other response directly to Red's question...] -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/