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
