Re: setuid(geteuid());?

> 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 pgman@candle.pha.pa.us               |  (610)
853-3000+  If your life is a hard drive,     |  830 Blythe Avenue +  Christ can be your backup.        |  Drexel Hill,
Pennsylvania19026