Path: utzoo!mnetor!uunet!munnari!moncskermit!goanna!yabbie!rcodi
From: rcodi@yabbie.rmit.oz (Ian Donaldson)
Newsgroups: comp.sys.apollo
Subject: Re: Running rn, rnews, etc on DN3000's / DSP90's
Message-ID: <681@yabbie.rmit.oz>
Date: 24 Jan 88 14:18:08 GMT
References: <8801201837.AA20797@BOEING.COM>
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Lines: 53

in article <8801201837.AA20797@BOEING.COM>, bcs212%psev@BOEING.COM (Vince Skahan) says:
> 	I'd appreciate any information available about running
> rn, rnews, and nntp on Apollo workstations.  Are there any 
> special considerations to be taken into account due to Apollo's
> implementation of unix ???  All of our nodes are currently
> at SR 9.6 and will probably remain there for quite a while.

Well, I ported news2.11, patchlevel 12 to SR9.2 some months back and 
ran into a few problems.

It seems that Apollo I/O checks the permission modes on every read/write
operation, rather than the traditional (and correct) UNIX way on open() only.

This breaks postnews, which opens a file in /tmp and then feeds it
to inews as stdin.  Inews is suid/sgid to news, and postnews isn't.
If your umask has bit 2 set (eg: 027 or 077) that causes files
created to -not- have "other" read access, then postnews will create
the file in /tmp with a mode that inews can't read!  AAARRGGH!

The fix (ie: hack) is simple - issue a chmod() inside 
postnews before calling inews.

Here is a fragment of the fixed code in "postnews.c":
-------
prep_article()
{
	FILE *tf, *of;
	struct stat stbuf;

	(void) strcpy(tempfname, "/tmp/postXXXXXX");
	MKTEMP(tempfname);

	/* insert a header */
	tf = xfopen(tempfname, "w");
#ifdef APOLLO	
	(void) chmod(tempfname, 0644);
#endif
	fprintf(tf, "Subject: %s\n", subject);
	fprintf(tf, "Newsgroups: %s\n", newsgroups);
-------

Whether this kernel bug is fixed beyond SR9.2, I don't know since we haven't
got a more recent version installed yet.

There was some other bug that I didn't fix in rnews that causes
it to cr*pout (ie: segmentation violation) somewhere when unbatching.
If you don't use batching of news, it seems to work ok though.

Not yet being sufficiently familiar with the Apollo debuggers, I
didn't bother pursuing the bug (I long for a core file and any
of adb/sdb/dbx :-(

Ian D