Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!unido!mikros!mwtech!mecky!walter
From: walter@mecky.UUCP (Walter Mecky)
Newsgroups: comp.unix.sysv386
Subject: Re: system(3) behaviour under Esix rev. D
Message-ID: <868@mecky.UUCP>
Date: 24 Feb 91 16:07:35 GMT
References: <1991Feb17.214252.27336@metro.ucc.su.OZ.AU>
Reply-To: walter@mecky.UUCP (Walter Mecky)
Organization: MIKROS Systemware, Buettelborn/W-Germany
Lines: 26

In article <1991Feb17.214252.27336@metro.ucc.su.OZ.AU> glenn@suphys.physics.su.OZ.AU (Glenn Geers) writes:
< 	I've got a program that is setuid root that runs a system command
< via the system(3) library routine. The problem is that I need the effective
< uid of the calling program to be inherited by the process run by system(3).
< Esix does not seem to do this. If I use my own fork/exec sequence I have no
< problems. The question is: Should system(3) really set the uid of the process
< it runs to the effective uid of the invoking program or to its real uid?
< I have RTFM'd and the former case seems correct but the latter is occuring.

I suppose the bad guy is not system(3) but sh(1). system(3) is calling
/bin/sh and I think in the mentioned fork/exec approach Glenn execed the
program directly not throuh /bin/sh.

I can not speak for ESIX, but in my system (SCO UNIX) this is a
(not documented) fact:

	sh resets the effective uid back to the real 
	uid if they are different and the EUID != 0.

I noticed this in ISC 2.02 too.

Ugly, very ugly, I think, not only because it's undocumented but it
annoys the responsible programmers as Ken (and me) for the sake of 
some careless ones.
-- 
Walter Mecky	[ walter@mecky.uucp	or  ...uunet!unido!mecky!walter ]