Peter Eisentraut <[EMAIL PROTECTED]> 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 the euid 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 member of 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
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
