Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!rice!hsdndev!husc6!ddl
From: ddl@husc6.harvard.edu (Dan Lanciani)
Newsgroups: comp.unix.ultrix
Subject: Re: Problems with rexecd under Ultrix 4.0
Summary: very old bug?
Keywords: rexecd MacX
Message-ID: <5087@husc6.harvard.edu>
Date: 16 Dec 90 06:39:50 GMT
References: <6960@uceng.UC.EDU>
Distribution: na
Organization: Harvard University, Cambridge MA
Lines: 37

In article <6960@uceng.UC.EDU>, tpitman@uceng.UC.EDU (Tom Pitman) writes:
| I am having a bit of a problem with the rexec daemon under Ultrix 4.0
| on both a Vax 8650 and a DECstation 5000/200.
| 
| I am running MacX on my Mac IIcx.  To initiate connections to other systems
| MacX uses the rexec protocol.  This works fine on most of our systems here
| on campus, ranging from Vaxen running VMS to IBM RTs running AIX to
| Suns running SunOS.  But for some inexplicable it will not work under
| Ultrix.
| 
| We have determined that rexec seems to work if the user on the Ultrix
| machine is either root or a member of group 0 (system group).
| In the syslog file a message like the following is logged when a
| mere mortal attempts to rexec to one of the ultrix boxes:
| 
| Dec  7 17:23:59 localhost: 11141 rexecd: setgid: Not owner
| 
| To verify that MacX was not the root of the problem, I wrote a small
| program using the rexec subroutine - with the same results.

	A long time ago, in early 4.2BSD, there was a bug in rexecd.
The code attempted to set the gid of the process *after* it had already
given up root uid.  That is, it did something like:

	initgroups()
	setuid()
	setgid()

	The return values from the set*() calls was not checked so the
error caused little more than slightly confusing behavior.  Now, though
it seems unlikely, perhaps someone went through the code adding checks
for success to each set*() function, failed to notice the error, and
failed to test the result of the changes.  Anyone with 4.x source
care to confirm?

				Dan Lanciani
				ddl@harvard.*