[net.news.b] sigtrap & setuid problems

gnu@sun.uucp (John Gilmore) (10/16/84)

> Any suggestions on what to do about this?  Maybe instead of #ifdef USG,
> someone should consider #ifdef SYS3, #ifdef SYSV (or something similiar).
> Comments?
How about "SYS3" and "SYS5" or "SYSIII" and "SYSV" but please don't mix
Roman and Arabic numbers...  Do the USG cpp's specify what version of
Unix they are?  What names do they use?

> > 2)	the name 'sigtrap' (an integer used globally in a few files)
> > 	is also the name of a function in /lib/libc.a .

Unfortunately various systems define _sigtrap, including early (and
late?) Unisoft systems and Fortunes.  For all I know it was in the
original MIT libraries from Nu Unix.  When I brought up netnews on a
friend's Fortune, it seems like the name was used as the springboard
routine for signals -- the kernel would jump you to _sigtrap which
would jump to the right signal handler.  Being an int variable
defined by netnews (which prevented the "real" _sigtrap from being
loaded from libc.a), jumping to it didn't work very well.

The fix as far as a portable netnews is concerned is:  don't use that
name.  Rename the variable "sigkludge" or something.  We mortals can do
it with #define but the master source should be fixed to use a totally
new name.

The fix as far as a Unix manufacturer is concerned is:  Don't put "_"
on library routines that should be invisible to the user.  This makes
them invisible to C programs anyway.

This is another aspect of the generic namespace problem; pre-set
#define's have been talked about but until now nobody has mentioned new
routines in libc as a problem.

craig@scorplx.UUCP (Craig Miller) (10/17/84)

> How about "SYS3" and "SYS5" or "SYSIII" and "SYSV" but please don't mix
> Roman and Arabic numbers...  Do the USG cpp's specify what version of
> Unix they are?  What names do they use?

	1)	Duhhhh....  Where did I come up with SYS3 and SYSV?  Boy,
		that was stupid...  You're right: SYSIII and SYSV should
		be used...
	2)	Our cpp, at least, only has these defined (note: since
		we don't have the source to this system, I did a strings -1
		on cpp and looked for strings that looked like they might
		be in the list...): unix, PWB, plexus, m68.  PWB? (the
		manual says this is a System III implementation, so what's
		the connection?  I thought PWB was an earlier release from
		Bell Labs...?)

> late?) Unisoft systems and Fortunes.  For all I know it was in the
> original MIT libraries from Nu Unix.  When I brought up netnews on a
> friend's Fortune, it seems like the name was used as the springboard
> routine for signals -- the kernel would jump you to _sigtrap which
> would jump to the right signal handler.  Being an int variable
> defined by netnews (which prevented the "real" _sigtrap from being
> loaded from libc.a), jumping to it didn't work very well.

	Oh, yeah.  I also think they came from MIT...  Don't both Unisoft
	and Fortune use that compiler and libraries (or some derivative
	of them)?  Talk about a tough bug to find...  (I learned alot
	about adb those couple of days...)

> The fix as far as a portable netnews is concerned is:  don't use that
> name.  Rename the variable "sigkludge" or something.  We mortals can do
> it with #define but the master source should be fixed to use a totally
> new name.

	Yup.  (how about it Rick?)  (by the way, a real easy kludge that
	I used was to stick a -Dsigtrap=Sigtrap in CFLAGS in Makefile - I
	don't suggest that that be used as the real fix, however...)

> The fix as far as a Unix manufacturer is concerned is:  Don't put "_"
> on library routines that should be invisible to the user.  This makes
> them invisible to C programs anyway.

	Maybe invisible functions and variables should be declared
	'static', if at all possible (if I understand what you
	mentioned above about how _sigtrap was used, it may have
	been possible to declare the function 'sigtrap' static
	in this case...).
-- 

Craig Miller
Honeywell Info. Systems, Billerica, Mass.
{decvax,harvard}!scorplx!craig (soon to be ..!ihnp4!we53!busch!dcm)

Anheuser Busch: the official brewery of Usenet...

rpw3@redwood.UUCP (Rob Warnock) (10/19/84)

> late?) Unisoft systems and Fortunes.  For all I know it was in the
> original MIT libraries from Nu Unix.  When I brought up netnews on a

For sure, for sure. Fortune's original starting point for their
port was a tape brought back from a visit we made to see Steve Ward
in July 1981. I am not sure we\\ they got anything later than that.
Further additons were (liberally) made from 4.1bsd and System-III.
(I stumbled on the need for "-Dsigtrap=Xsigtrap" myself when putting
up 2.10.1 news. Oh well.)

Rob Warnock

UUCP:	{ihnp4,ucbvax!amd}!fortune!redwood!rpw3
DDD:	(415)572-2607	(*new*)
Envoy:	rob.warnock/kingfisher
USPS:	510 Trinidad Ln, Foster City, CA  94404	(*new*)

ka@hou3c.UUCP (Kenneth Almquist) (10/22/84)

> > Maybe instead of #ifdef USG, someone should consider #ifdef SYS3,
> > #ifdef SYSV (or something similiar).  Comments?
> How about "SYS3" and "SYS5" or "SYSIII" and "SYSV" but please don't mix
> Roman and Arabic numbers...  Do the USG cpp's specify what version of
> Unix they are?  What names do they use?

AT&T UNIXes simply predefine "unix" to indicate the operating system.
(Probably that's to convince people to upgrade to the latest version. :-))
The scheme I have developed for vnews uses two variables; one for V7 and
its derivatives from Berkeley, and the other for USG (now USDL) UNIX.  The
scheme is:

			    BSDREL  USGREL
	Sixth Edition		 6	 6
	Version 7		 7	 6
	4.1 BSD			41	 6
	4.2 BSD			42	 6
	System III		 6	30
	System V		 6	50
	System V Release 2	 6	52

This scheme has problems.  There is no room for 4.1C BSD.  2.x BSD should
perhaps have its own release number variable, but I was assuming that the
4.1 BSD code work for 2.x BSD.
				Kenneth Almquist