Re: setuid(geteuid());?

Peter Eisentraut <peter_e(at)gmx(dot)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 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