Path: utzoo!attcan!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.mail.sendmail
Subject: Re: Non-root sendmail?
Message-ID: <488@auspex.UUCP>
Date: 22 Nov 88 19:52:01 GMT
References: <164@heart-of-gold> <3031@haven.umd.edu> <13145@ncoast.UUCP> <132@minya.UUCP>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 23

>Of course, there are rumored to be versions of Sys/V which "remembers" old
>ids (specifically, root, when run from cron) and provide some way of getting
>back the old id even though it differs from getuid() and geteuid().

Every version of System V since at least System V Release 2 will, when
you run a set-UID program, remember both the "real" UID (generally the
one in effect when the program was "exec"ed) and the UID to which the
program is set-UID, and will permit you to use the "setuid()" call to
switch the effective UID back and forth between them an arbitrary number
of times - with one exception: if the effective UID is "root",
"setuid()" will set the real, effective, and "save set-user" UIDs to the
specified UID.

Except for the latter glitch, this is a win; it allows a set-UID program
to do privileged operations, then do operations with the credentials of
the user (without having to muck with "access()").  The intent behind
the aforementioned glitch is presumably to allow programs such as
"login" or "su" to set all the IDs.  SunOS also supports the saved
set-user ID notion; since it has "setreuid", it permits even set-UID
"root" programs to set the effective UID back and forth.  Systems that
have "setreuid", including SunOS, also generally permit you to exchange
the real and effective UIDs; this provides another way for programs to
switch back and forth.