> 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...
I don't even want to twist my brain far enough to understand this. So
basically. BSD/OS is safe with a seteuid executable if we keep the
setuid(geteuid()) call, while other OS's have serious problems we can't
plug. I knew there was some OS-specific stuff in setuid. Seems a check
that uid and euid are the same and not root is the way to go.
--
Bruce Momjian | http://candle.pha.pa.us
[EMAIL PROTECTED] | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?
http://www.postgresql.org/search.mpl
