Re: setuid(geteuid());?

Peter Eisentraut <peter_e@gmx.net> writes:
> Bruce Momjian writes:
>> so why does your test work?  Does your manual say something different?
>> If setuid() sets user/effective/saved to postgres, how can you get back
>> root?

> : setuid  sets  the  effective user ID of the current process.  If the
> : effective userid of the caller is root, the real and saved user ID's
> : are also set.

HPUX has an even more bizarre definition:
    setuid() sets the real-user-ID (ruid),effective-user-ID (euid), and/or    saved-user-ID (suid) of the calling
process. The super-user's euid is    zero.  The following conditions govern setuid's behavior:
 
         o  If the euid is zero, setuid() sets the ruid, euid, and suid to            uid.
         o  If the euid is not zero, but the argument uid is equal to the            ruid or the suid, setuid() sets
theeuid to uid; the ruid and            suid remain unchanged.  (If a set-user-ID program is not            running as
super-user,it can change its euid to match its            ruid and reset itself to the previous euid value.)
 
         o  If euid is not zero, but the argument uid is equal to the            euid, and the calling process is a
memberof a group that has            the PRIV_SETRUGID privilege (see privgrp(4)), setuid() sets            the ruid to
uid;the euid and suid remain unchanged.
 

Rule #2 is what creates the security hole.  Rule #3 would allow us to
plug the hole, but only if we have PRIV_SETRUGID...
        regards, tom lane