Path: utzoo!utgpu!water!watmath!clyde!rutgers!umd5!uvaarpa!hudson!slb
From: slb@hudson.acc.virginia.edu (Sandy Bryant)
Newsgroups: comp.unix.wizards
Subject: Re: setreuid() functionality in sysV
Message-ID: <172@hudson.acc.virginia.edu>
Date: 21 Jan 88 00:34:09 GMT
References: <1988Jan19.192854.3411@jarvis.csri.toronto.edu>
Reply-To: slb@virginia.edu (Sandy Bryant)
Organization: University of Virginia, Charlottesville
Lines: 37

In article <1988Jan19.192854.3411@jarvis.csri.toronto.edu> rayan@ai.toronto.edu (Rayan Zachariassen) writes:
..I'm trying to simulate the effect (within a root process) of the BSD construct:
..
..	setreuid(0, uid);
..	...
..	setreuid(0, 0);
..
..The important thing being that the '...' is run with effective uid 'uid',
..and that both real and effective uid are restored to 0 afterwards.
..
..Now, the SysV manual for setuid() says that
..
..	setuid(uid);
..	...
..	setuid(0);
..
..is possible iff 0 is the "saved set_user id" and refers to exec(2).
..Of course, exec(2) doesn't mention this concept.  What does "saved set_user id"
..mean? 

There is a field in the user struct that saves the effective uid
for a setuid program at exec.  This usually allows you to switch 
your effective uid back and forth between your real uid and the original 
effective uid at will.  Problem is that whenever *root* calls setuid(),
everything - real uid, effective uid, AND the saved set_user id field in 
the user struct are all set to the new uid, so you can never go back to 
being root again.  To do otherwise creates a security hole, I guess.  
If you can use some other "priviledged" id besides root to own those 
files, you can do what you want.

This was true in SVR2, SVR2.1, and SVR3 on the AT&T 3B's, and I assume
it is standard SV behavior.  The man page does day that when root calls
setuid, both effective and real uid are set.

sandy

sandy