setuid (euid) after setuid (uid) on System 5

[Guy Harris]

>This works on my System V 3.2.1 system only if the program is not
>set-uid to root.  If it is set-uid to something else (like uucp in the
>HoneyDanber stuff) then it works.  I'm not sure why it shouldn't work
>for root.

It shouldn't work for root because they decided not to make it work for
root.

The problem is that "setuid" can mean two things:

	1) "I'm running set-UID, but want to change back - possibly
	   temporarily - to my real UID, and then be able to change to
	   my original set-UID effective UID again;"

	2) "I'm a program such as 'login', and am running as root; I
	   want to set the user ID for a newly created session - real,
	   effective, and original set-UID effective UIDs - to some
	   value."

(The "original set-UID effective UID" is generally referred to as
something like the "saved set-user ID" in S5 documentation.)

Instead of providing new calls based on the 4.2BSD "setreuid" call -
that call can independently set the real and effective UIDs, and can be
told to leave one of the UIDs alone by supplying -1 as an argument -
they overloaded "setuid".  They did so by making it act differently for
an effective UID of 0 (or maybe it was real UID, our S5R3 sources aren't
on-line at the moment) than for other effective UIDs.

I suspect S5R4 and 4.4BSD may end up following the SunOS lead on this
one; "setreuid" was enhanced to support an S5-style "saved set-user ID",
so that you can do the following in a set-UID program:

	ruid = getuid();
	euid = geteuid();
	<stuff with the effective user ID equal to the set-user ID>
	seteuid(ruid);
	<stuff with the effective user ID equal to the real user ID>
	seteuid(euid);
	<stuff with the effective user ID equal to the set-user ID>

regardless of whether the effective or real user ID is 0 or not.

Both BSD and S5 flavors of "setuid" can be implemented atop "setreuid".