Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!ihnp4!qantel!lll-lcc!pyramid!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.bugs.usg
Subject: Re: Problems with setuid(), SVr2v2 - (nf)
Message-ID: <7677@sun.uucp>
Date: Fri, 26-Sep-86 15:22:55 EDT
Article-I.D.: sun.7677
Posted: Fri Sep 26 15:22:55 1986
Date-Received: Tue, 30-Sep-86 06:42:44 EDT
References: <4100002@siedap.UUCP> <102@netxcom.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 27

> Same is true on Xenix System V -- apparently you can give up root priv's
> by turning on the set-uid bit on an executable owned by someone other
> than root, but you can't get them back by doing a setuid() back to
> the real uid of 0.  It does work correctly for all other real uid's.

This is true on S5 as distributed by AT&T-IS, and presumably Microsoft left
that code alone.  The trouble is that there are really at least *two
different* "setuid" operations in modern UNIX systems:  one that sets the
real *and* effective *and* saved set-user IDs - this one is used by "login"
and "su", for setting the environment of a user - and one that sets *only*
the effective ID, used for giving up or regaining privileges in a set-UID
program.

Unfortunately, System V isn't modern enough; they didn't pick up the 4.2BSD
"setreuid" system call, which permits you to set both user IDs
independently.  Instead, they overloaded "setuid".  If the argument to
"setuid" is non-zero, and it matches either the real or saved set-user ID,
it is treated as the second kind of "setuid", which sets only the effective
UID.  Otherwise, it is treated as the first kind of "setuid", which sets
them both; this version is, of course, restricted to the super-user.

Thus, "setuid(0)" is always treated as the first kind of "setuid", and since
the set-UID program's effective UID isn't root, it fails.
-- 
	Guy Harris
	{ihnp4, decvax, seismo, decwrl, ...}!sun!guy
	guy@sun.com (or guy@sun.arpa)