Xref: utzoo comp.unix.wizards:15125 comp.bugs.sys5:813
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wasatch!cs.utexas.edu!tut.cis.ohio-state.edu!ukma!rutgers!att!petsd!pedsga!jeffj
From: jeffj@pedsga.UUCP
Newsgroups: comp.unix.wizards,comp.bugs.sys5
Subject: Re: setuid (euid) after setuid (uid) on System 5
Summary: It's the secret hidden saved set-uid to the rescue
Message-ID: <822@pedsga.UUCP>
Date: 21 Mar 89 00:08:18 GMT
References: <123@cat.Fulcrum.BT.CO.UK>
Organization: Concurrent Computer Corp. Tinton Falls, N.J.
Lines: 81

In Message-ID: <123@cat.Fulcrum.BT.CO.UK>, Ian G Batten asks:
>Should the following program work or not, on System Five?  This is a
>common idiom in the source code of HoneyDanber uucp, and two local System
>Five machines refuse to honour the second setuid.  The manual page implies
>they should.  Please, no flames --- just mail me an answer.  I've been
>sweating blood over the code all day and I hope I can lodge this as a
>kernel problem.
>
>ian
>
>main ()
>{
>  int uid, euid;
>
>  printf ("uid = %d; euid = %d\n", uid = getuid (), euid = geteuid ());
>  if (setuid (uid) != 0)
>    perror ("setuid (uid)");
>  printf ("uid = %d; euid = %d\n", getuid (), geteuid ());
>  if (setuid (euid) != 0)
>    perror ("setuid (euid)");
>  printf ("uid = %d; euid = %d\n", getuid (), geteuid ());
>}
>-- 

Sounds like a kernel bug to me.
A problem setting the SAVED SET-UID to be precise.
Let me explain:

Assuming this is not run as UID 0, let's look at the manual.
A process has a REAL UID that identifies the person running the process.
	Only root can change this, so this is invariant.
The EFFECTIVE UID determines the permissions.
	It is the same as the REAL UID, unless the SET UID bit is on,
	then the EFFECTIVE UID is that of the file.
The SAVED SET-UID is the effective UID of the process before
	an exec().  If the previous process was not SET-UID,
	the SAVED-SET UID is the same as the effective UID.
	This is to allow the effective UID to alternate between
	the real UID and its previous value.

So, setuid() as a non-root allows the process to set the EFFECTIVE
UID to the REAL UID, or the SAVED UID.

Let's say this a.out has no set-uid.
This runs okay, telling me uid=euid=44 all the time.

Now try this a.out set-UID 44, run it as UID 33.
The output is
	REAL	EFFECTIVE
	33	44
	33	33
	33	44
The first setuid sets the effective UID from 44 to the real (33).
Now you want to set it back.
The secret hidden SAVED SET-UID holds the UID 44, so the second call
succeeds.  Unless, of course, this was exec'd from something
set-UID something-not-UID 44.
Perhaps crash(1M) displays the saved set-uid?
Perhaps the saved-uid was erroneously set to the real UID?

__________
		UN*X
		UNIX (ver 6, ver 7, PWB, Sys III, Sys V)
		AIX
		BSD (4.0, 4.1, 4.2, 4.3)
		MINIX
		REGIS
		RTU
		T/PIX
		ULTRIX
		UTS
		VNIX
		XENIX
		XINU
		your-version-here
	
Jeffrey Jonas

INTERNET: jeffj@pedsga.tinton.ccur.com
USENET: allegra!io!mtune ---------> petsd!pedsga!jeffj
        decvax!mcnc!rutgers _____/