Path: utzoo!utgpu!water!watmath!clyde!bellcore!tness7!killer!pollux!dalsqnt!rpp386!jfh
From: jfh@rpp386.UUCP (John F. Haugh II)
Newsgroups: comp.unix.wizards
Subject: Re: System V.2.2 setuid() broken
Message-ID: <3942@rpp386.UUCP>
Date: 14 Jul 88 05:06:07 GMT
References: <5968@umn-cs.cs.umn.edu> <2820@ttidca.TTI.COM> <58603@sun.uucp> <3475@sequent.UUCP> <59537@sun.uucp> <1305@basser.oz>
Reply-To: jfh@rpp386.UUCP (The Beach Bum)
Organization: Big "D" Home for Wayward Hackers
Lines: 39

In article <1305@basser.oz> boyd@basser.oz (Boyd Roberts) writes:
>I'm root and I run a non-root setuid executable.  Then I want
>to fork() a shell and do the usual:
>
>	setuid(getuid())
>
>Of course, I get EPERM, because setuid() is broken.  Now is this
>a generic System V bug.  I think it is.  Clarification please?

no, according to SETUID(2), you got the correct behaviour, and on
close examination, that is the CORRECT behavior.

consider, running the a.out SUID sets the EFFECTIVE UID to the
non-root user.  getuid(2) returns the REAL UID which equals
ROOT.  and from the manual

	Setuid (setgid) will fail if the real user (group) ID
	of the calling process is not equal to uid (gid) and
	its effective user ID is not super-user. [ EPERM ]

the real user ID is ROOT and the uid is ROOT.  however, the
effective user ID is not ROOT, so the call fails with EPERM.

this `feature' prevents a trojan horse from doing a

	if (getuid () == 0) {
		setuid (0);
		chown ("/bin/sh", 0, 0);
		chmod ("/bin/sh", 04711);
	}

thereby giving you the famed password free su command.

- 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@rpp386.uucp          |             -- with my apologizes