HDTenEightyP/NetNews huggingface dataset:
From: maziere1@husc8.harvard.edu (David Mazieres)
Newsgroups: comp.unix.sys5.r4
Subject: SUID shell script weirdness
Date: 8 Jan 93 21:04:52 GMT
Article-I.D.: husc3.1993Jan8.160453.19117
Distribution: world
Organization: Harvard University Science Center


I have been experiencing an extremely bizarre problem with SETUID shell
scripts on SVR4 (Consensys), and would appreciate any advice.

First, the kernel actually allows SETUID shell scripts (without a C
wrapper, that is).  Does this mean the "exec a symbolic link to a
SUID shellscript + quickly change to a different file" bug has been
fixed in SVR4?  If not, how do I disable SUID shell scripts in the
kernel.  I checked the description of all the mtune parameters in
the System Administrator's Guide, but couldn't find anything having
to do with this.

Second, and even more disturbing, the plain old "/bin/mkdir" (not
SETUID) appears to be able to do things it is not supposed to be
able to do.  I am running with RSTCHOWN set to 1 in the kernel (i.e.
BSD-style chown and chgrp restrictions).  Now, I quote from the
mkdir (2) man page:

     The directory's owner ID is set to the  process's  effective
     user  ID.   The directory's group ID is set to the process's
     effective group ID, or if the SETGID bit  is  set  in  the
     parent  directory,  then  the  group  ID of the directory is
     inherited from the parent.

And yet, observe the following behaviour:

> id
uid=100(dm) gid=100(oper)
> ls -al sh
-r-sr-xr-x   1 font     oper        63992 Jan  8 12:55 sh
> ./sh
$ id
uid=100(dm) gid=100(oper) euid=108(font)
$ cd /tmp
$ /bin/mkdir suid_bug
$ ls -ald suid_bug
drwxr-xr-x   2 dm       oper          512 Jan  8 15:35 suid_bug
$ /bin/rm -rf suid_bug
rm: Unable to remove directory
Permission denied
$ /usr/local/gnubin/rmdir suid_bug
/usr/local/gnubin/rmdir: suid_bug: Permission denied
$ /bin/rmdir suid_bug
$ /usr/local/gnubin/mkdir suid_bug
$ ls -ald suid_bug
drwxr-xr-x   2 font     oper          512 Jan  8 15:36 suid_bug
$ /bin/rmdir suid_bug
rmdir: suid_bug: Search or write permission needed
$ /bin/rm -rf suid_bug
$ > exit

Process shell finished

That's right, "/bin/mkdir" and "/bin/rmdir" only seem to work with the
real, rather than effective user id's.  But with RSTCHOWN set to 1,
those programs shouldn't even be allowed to create files with UID's
other than the current EUID.  I looked a the source for the GNU version
of mkdir, and it just uses mkdir(2), which behaves as expected.

So, what does the AT&T mkdir(1) use to make it's directories, and why?
(I know it doesn't to a flat out seteuid(getuid()), because I still need
write permission on the parent directory.)  This is really annonying in
SUID shell scripts that need to create temporary directories, as those
scripts cannot create files in the directories they just created.  Should
I just use GNU mkdir, or is there some major security hole that I'm
overlooking?

Thanks for any help.  Please reply via E-Mail, and I'll post a summary if
the solution is anything non-trivial.  (Please let me know explicitly if
you would object to my quoting your reply in the follow-up article.)

david (maziere1@husc.harvard.edu)
From: bruno@athena.mcrcim.mcgill.edu (Bruno Hall)
Newsgroups: comp.unix.sys5.r4
Subject: Re: Public Domain SLIP/PPP on SVR4.
Date: 6 Jan 93 22:56:53 GMT
Organization: McGill University Broom Closet

troy@centerline (Troy Runkel) writes:

>  I am currently setting up an NCR486 machine running System V.4.
>Unfortunately the system doesn't seem to come with SLIP so I was
>wondering if anybody out there knew of a publicly available version 
>of SLIP, Compressed SLIP, or PPP that would work under System V.4
>streams.  Thanks in advance.

Sure:

rapfast.unibase.sk.ca:slip.tar.Z 			compressed SLIP
svin02.info.win.tue.nl:pub/sysvX86/slip.ix.386.shar.Z	SLIP
svin02.info.win.tue.nl:pub/sysvX86/slip.V4		SLIP

I too would like to know where free PPP sources for SVR? can be found.

Bruno
-- 
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
Bruno Hall  |  VE2HUM  |  bruno@mcrcim.mcgill.edu         
McGill Research Centre for Intelligent Machines - Controls Group
New systems generate new problems -- Join the Flat Earth Society.
Newsgroups: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
From: jp@tygra.Michigan.COM (John Palmer)
Subject: Re: Netblazer
Organization: CAT-TALK Conferencing System
Date: Sun, 10 Jan 1993 14:22:47 GMT

In article <C0JL0L.HEx@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
"karl@ddsw1.mcs.com (Karl Denninger) writes:
"
">>>Can the NB support 2 56700 baud modems going full blast on the
">>>stock 2 serial ports on the motherboard?
">>
">>try pulling the case off and seeing of the UARTs are 16550's.
">>
">>i would suspect so.
"
">They certainly are.  (I have examined lots of these)
"
"So one can assume they support the FIFO to get those speeds.
"

The best bet in using the Netblazer for dialup IP is to ignore the first
two ports as they are built into the board and are standard AT serial
ports. The 8-port cards are Digiboard PC/8e's. You can take one out of
the box and plug it into your Netblazer and it will work fine. There are
instructions in the Netblazer manual on how to set the dip switches. 
-- 
Its most likely a     | E-MAIL: jp@michigan.com  CAT-TALK IS BACK as a FREE
forgery, so save your | SYSTEM!! 313-882-2209 300-14400 V.32/V.32BIS/TurboPEP
flames for someone    | Anon-UUCP: System: tygra, Login: nuucp, no pw
who cares  :->        | Get file "/cat/pub/filelist" for a list of files.
Newsgroups: comp.unix.sys5.r4,comp.unix.questions,comp.unix.sysv386
From: larry@news.rn.com (Larry Snyder)
Subject: Re: What is lacking in UNIX? (Re: UNIVEL MUST BE KIDDING!!!!!)
Organization: Gator Communications - Feeds-R-Us 219-289-3745 
Date: Tue, 5 Jan 1993 20:25:51 GMT

peter@ferranti.com (peter da silva) writes:

>> Well you haven't seen Dell SVR4 2.2 (release 4.0).  One can boot off the boot
>> disk, switch to the system disk when prompted, then exit to the shell and 
>> mount your hard disk drives and modify (and execute) your applications 
>> to you hearts content.

>Well, that's certainly a good first step, getting back to where Xenix was in
>'85. What is on the system disk? (mount, umount, cat, fsck, cpio, mkfs, dd,
>echo, ls, df, ...?) How well is this documented? Can you remove the system
>disk, insert another floppy, and mount it?

What happens is that mount, find, etc is copied to ram disks and executed
from there.  You can execute the tools from the ram disks to mount the hard
drives and I would think floppies (I haven't tried mounting floppies, but
I believe that is is possible since the networking disk is mounted
from the ram disk (which enables one to do a complete OS install -- including
the add-on packages like cnews, gnu, etc over a network -- what happens is
that you are prompted for the IP address and directory paths to the server
from the inet installation disk -- and presto -- the base OS and selected
packages are copied over the network).  I don't know exactly what tools on
copied to the ram disk -- but I know mount, mkfs, dd, and find are..

Is this documented?  I don't think it completely is --

At boot time, you are prompts for a network installation, tape installation
or system administration -- the latter of which dumps you with a shell prompt
to poke around :)

-- 
Larry Snyder                                    internet: larry@gator.rn.com
keeper of the Gator                                  uucp: uunet!gator!larry
Newsgroups: comp.unix.sys5.r4,comp.unix.questions,biz.comp.telebit.netblazer,comp.protocols.tcp-ip
From: bob@MorningStar.Com (Bob Sutterfield)
Subject: VJ compression (Re: Netblazer)
Organization: Morning Star Technologies
	<1993Jan07.224637.4538@xenitec.on.ca> <C0JFMF.4nu@ddsw1.mcs.com>
	<C0JL58.HqK@news.rn.com>
Date: Fri, 8 Jan 1993 17:20:41 GMT

In article <C0JL58.HqK@news.rn.com> larry@news.rn.com (Larry Snyder) writes:
   Would VJ compression with SLIP be benificial even if you have
   hardware compression (v.42bis?).  If so, how much?

Yes, because RFC-1144 "VJ" TCP header compression and V.42bis do
different things.  The former is application-specific to TCP datagram
headers, so it can be very efficient at its narrow mission.   The
latter is a general-purpose data compressor, so it does a fair job on
lots of different data.

RFC-1144 reduces the number of overhead octets with which each TCP
datagram is afflicted.  It does nothing with the fare-paying cargo
inside the packet.  A typical single-character telnet packet shrinks
from forty-something to 5-8 octets, reducing transmission time and
therefore dramatically reducing interactive latency.

V.42bis is a general purpose data compression algorithm that
compresses everything that passes through the modem - overhead and
data alike.  V.42bis processing actually adds a little latency, but
not so much as to be objectionable.  And its effect on shrinking the
total size of the packets helps a *lot*.  You'll often see over 3Kb/s
FTP throughput over a V.32bis (14400) carrier with a 38400 DTE, with
very little (if any) adverse effect on latency.
--
Bob Sutterfield, Morning Star Technologies            +1 614 451 1883
1760 Zollinger Rd, Columbus Ohio USA, 43221           +1 800 558 7827
bob@MorningStar.Com                                   +1 614 459 5054 (FAX)
Newsgroups: comp.unix.sys5.r4,comp.unix.sysv386
From: vagarwal@dis9002.shearson.com (Virendra Agarwal)
Subject: Re: Will Dell load off a Wangdat DAT?
Reply-To: vagarwal@tardis.shearson.com
Organization: Lehman Brothers
	<1993Jan03.061458.8353@catfish.az05.bull.com>
	<PCG.93Jan4044924@decb.aber.ac.uk>
	<1993Jan05.235754.15744@catfish.az05.bull.com>
	<1993Jan6.141548.24476@crd.ge.com>
Date: Mon, 11 Jan 1993 19:29:16 GMT

  
	DELL Unix :
	----------
	Does DELL sell Unix as a package or packaged with its HARDWARE ?


--
---------------------------------------------------------------
Virendra Agarwal
vagarwal@shearson.com
212-464-2151
Lehman Brothers
388 Greenwich st.(9th Flr.)
NewYork, NY 10013
---------------------------------------------------------------
From: walter@mecky.rent-a-guru.de (Walter Mecky)
Newsgroups: comp.unix.sys5.r4
Subject: Re: Where did /usr/bin/truss originate?
Date: 13 Jan 93 01:11:32 GMT
Reply-To: walter@rent-a-guru.de (Walter Mecky)
Organization: RENT-A-GURU (tm), Buettelborn; FR Germany

In article <JHPB.93Jan10205357@sarto.budd-lake.nj.us> jhpb@sarto.budd-lake.nj.us (Joseph H. Buehler) writes:
< In article <1993Jan9.200455.28681@sinkhole.unf.edu> shite@sinkhole.unf.edu (Stephen Hite) writes:
< 
< 	  I have Esix 4.0.3a.  It came with a nice utility called truss,
<    located in /usr/bin.   I thought this was part of the standard
<    USL source release of SVR4.   However, our company just got in SVR4
<    from Harris (running on a Night Hawk 4400) and truss is not on the 
<    system.  Does anyone know the origin of the truss utility (i.e., is
<    it from Sun or made just for the i386/i486 platform of Unices?).  Thanks
<    for the info! 
< 
< Truss *is* wonderful, isn't it?

Yes, I think so too. But from the very first days I played with this
nice tool I'm waiting for the day that now has come: a vendor cares
about the knowledge truss gives about his code. Truss often shows very
poor programming and obvious errors.

Is this not a reason for a vendor to "unbundle" it from the
distribution?

-- 
   __o          Walter Mecky
 _ \<,_         walter@rent-a-guru.de   or   ...uunet!unido!mikros!walter
(_)/ (_)        Phone: +49 6152 40813
Newsgroups: comp.unix.sys5.r3
From: umcarls9@ccu.umanitoba.ca (Charles Carlson)
Subject: Why does ISC hang on boot w/AHA1542A?
Organization: University of Manitoba, Winnipeg, Canada
Date: Wed, 6 Jan 1993 18:56:57 GMT


I just picked up an Adaptec 1542A and I'm trying to get it to work with
ISC 3.2 2.2.1 as a secondary controller. (IDE drives are used for boot).

The system comes up with Booting.... the LED on the SCSI drive as well as
on the controller come on, and off a few times, then the controller light
comes on again for a second or two, then goes off, and the system just
hangs.  If I power off the SCSI drive and reboot, the controller light
behaves the same way, then the system boots normally, with AHA init reporting
0 SCSI devices.

I have tried this with the BIOS both enabled and disabled, same result.
Rom version is 3.02 dated 1988.

I have the controller set to all the defaults, ie, IRQ 11, iobase 330,
rom at DC00, DMA channel 5, floppy disabled, etc.  

The controller works just fine as a primary controller under DOS.

When I tried to build a kernel for AHA, I got several errors saying it couldn't
find any of the routines for the Future Domain (ie, FDC_INTR, FDC_CTL_INIT)
and the PS/2 devices first referenced in /etc/conf/pack.d/dsk/Space.o.  
Deleting those references in Space.c made the kernel build OK, this obviously
isn't the proper solution so something else must be wrong.

Any idea as to what I did wrong?? 

Thanks....
-- 
/ Charles Carlson  umcarls9@ccu.Umanitoba.CA  
\ This .sig now available on a limited edition 2 record set, for 4 easy 
/ installments of $19.95 each. To order, please have your Visa or Mastercard
\ ready and phone: 1-800-555-1212, or send check or MO to 200-155 Carlton St.
Newsgroups: comp.unix.sys5.r3
From: cmhui@cs.cuhk.hk (Hui Chau Man)
Subject: How to compile X11R5 on UNIX SYSV/68 Release 3 Version 6?
Organization: Faculty of Engineering, The Chinese U. of Hong Kong
Date: Thu, 7 Jan 1993 02:42:37 GMT

Dear Netters:

Recently, I bought a X window system from MIT. It is X11R5. I want to compile
the system on my host, which is a VME147 plus the UNIX SYSV/68 Release 3 Version
6 as the O/S. As you may know, I encounter so many problems such as the lack of
Unix Domain Socket on my O/S.

Does anybody know what should I do to compile the X window system on my host? I
know there are new version for my O/S, which is version 7 provided by Motorola.
Do you know whether the new version O/S has features the X windows needs?

Thanks in advance

C.M. Hui
Dept. of Computer Science
The Chinese University of Hongkong
Shatin, N.T.
Hongkong

Internet: cmhui@cucs18.cs.cuhk.hk
FAX: (852) 6035024

Xref: sparky comp.unix.sys5.r3:168 biz.sco.general:4975
From: mju@mudos.ann-arbor.mi.us (Marc Unangst)
Newsgroups: comp.unix.sys5.r3,biz.sco.general
Subject: Re: PD "C" Compiler for SCO?
Date: 5 Jan 1993 00:39:38 -0500
Organization: The Programmers' Pit Stop, Ann Arbor MI
NNTP-Posting-Host: mudos.ann-arbor.mi.us

In article <1iafg3INNrji@usenet.INS.CWRU.Edu> ba014@cleveland.Freenet.Edu (Matthew C. Brinkhoff) writes:
>Is there a public domain development system for SCO Unix SVR3.2.4?  I've
>heard of "GCC", but are there SCO binaries available anywhere?

Yes, you can download GCC binaries for SCO.  However, unless you have
the development system they won't do you any good, since GCC doesn't
supply system libraries or include files.  I'm afraid you will just
have to bite the bullet and buy the development system from SCO.

-- 
Marc Unangst, N8VRH         | "Of course, in order to understand this you
mju@mudos.ann-arbor.mi.us   |  have to remember that the nucleus of the atom
                            |  is squishy."
                            |    -W. Scheider, from a Physics lecture
From: klein@atmkn.UUCP (A.Klein)
Newsgroups: comp.unix.sys5.r3
Subject: EXABYTE 8500 and ISC 3.0
Keywords: Exabyte, Interactive, ISC
Date: 12 Jan 93 10:58:33 GMT


Does anyone know, if an Exabyte 8500 works under ISC 3.0 ?
The official compatibility list says, you can use an Exabyte 8200,
but nothing about an 8500. Do one need an additional driver ?

Thanks a lot,

Andreas Klein



------------------------------------------------------------------------snip--
     Andreas Klein     | ATM Computer GmbH | Email: klein@atmkn.uucp  
   _    _____  _    _  |     Abt. ED1      |        klein%atmkn@Germany.EU.net
 /   \ |_   _||  \/  | | Buecklestr. 1 - 5 |  
| AEG |  | |  |      | |  W-7750 Konstanz  | Voice: +49 7531 807559      
|_| |_|  |_|  |_|  |_| |     Germany       | Fax:   +49 7531 807280 
------------------------------------------------------------------------------
From: cq267@cleveland.Freenet.Edu (Jeremy Fox)
Newsgroups: comp.unix.sys5.r3
Subject: How to set up SLIP: V/3.2
Date: 11 Jan 1993 01:09:00 GMT
Organization: Case Western Reserve University, Cleveland, OH (USA)
Reply-To: cq267@cleveland.Freenet.Edu (Jeremy Fox)
NNTP-Posting-Host: hela.ins.cwru.edu


I'm trying to set up a SLIP connection for a V/3.2 system.  We already
have all the modems.  All the shareware SLIP products seem to be aimed
at version 4 users or Suns.  Does anyone know how I where I could get
files for 3.2, or how I could modify version 4 files?  Has anyone here
succesfully installed SLIP on version 3 before?  Does anyone have SLIP
running on their machine, even if it isn't working? Thanks.

Jeremy Fox
cq267@cleveland.Freenet.Edu
Xref: sparky comp.unix.sys5.r3:169 biz.sco.general:4982
From: davidsen@ariel.crd.GE.COM (william E Davidsen)
Newsgroups: comp.unix.sys5.r3,biz.sco.general
Subject: Re: PD "C" Compiler for SCO?
Date: 5 Jan 93 17:22:29 GMT
Reply-To: davidsen@crd.ge.com (bill davidsen)
Organization: GE Corporate R&D Center, Schenectady NY

In article <1ib6uqINNam7@mudos.ann-arbor.mi.us>, mju@mudos.ann-arbor.mi.us (Marc Unangst) writes:
| In article <1iafg3INNrji@usenet.INS.CWRU.Edu> ba014@cleveland.Freenet.Edu (Matthew C. Brinkhoff) writes:
| >Is there a public domain development system for SCO Unix SVR3.2.4?  I've
| >heard of "GCC", but are there SCO binaries available anywhere?
| 
| Yes, you can download GCC binaries for SCO.  However, unless you have
| the development system they won't do you any good, since GCC doesn't
| supply system libraries or include files.  I'm afraid you will just
| have to bite the bullet and buy the development system from SCO.

  Thought the latest gcc release including the libs and includes. So I
read in another group.
-- 
bill davidsen, GE Corp. R&D Center; Box 8; Schenectady NY 12345
    Keyboard controller has been disabled, press F1 to continue.
Xref: sparky comp.unix.sys5.r3:185 comp.unix.programmer:5873 biz.sco.general:5041
From: ti@bazooka.amb.org (Ti Kan)
Newsgroups: comp.unix.sys5.r3,comp.unix.programmer,biz.sco.general
Subject: Compiler wierdness alert...
Date: 9 Jan 93 20:15:31 GMT
Reply-To: ti@bazooka.amb.org (Ti Kan)
Followup-To: comp.unix.sys5.r3
Organization: AMB Research Labs, Sunnyvale, CA.


Consider the following program:

----------------------------------
#include <stdio.h>

#pragma pack(1)
union foo {
	char d1;
	long d2;
};
#pragma pack()

struct bar {
	char a;
	char b;
	char c;
	union foo d;
};

main()
{
	struct bar x;

	/* display the relative offsets of struct bar members */
	printf("\t%d %d %d %d\n",
		(char *) &x.a - (char *) &x,
		(char *) &x.b - (char *) &x,
		(char *) &x.c - (char *) &x,
		(char *) &x.d - (char *) &x);
}
----------------------------------

Program output (Compiled with cc on 3.2v2 DS or or gcc 2.2.2):

	0 1 2 4

Program output (Compiled with cc 3.2v4 DS, or rcc on both 3.2v2 DS
and 3.2v4 DS):

	0 1 2 3

So, with cc on 3.2v4 or rcc in both versions, the compiler does not put
a pad byte after field "c" in struct bar, whereas with cc on
3.2v2 DS or gcc, it does.

What significance is there?  Well, for most applications writers
there isn't a problem, as long as all modules that use this structure
are compiled with the same compiler.  There will be a problem if you
are going to be mixing object files or libraries compiled with different
compilers.

For device driver writers, there is definitely a problem.  If there
is a kernel structure defined as such, and the kernel was compiled with
a different compiler than yours, then there is a serious bug.

Guess what, there is exactly such a case.  In /usr/include/sys/scsi.h,
on both SCO 3.2v2 and 3.2v4, there is a "scsi_io_req" structure which
contains a subfield "union scsi_cdb".  The starting offset of this
union varies depending upon which compiler you use.

It appears that the SCO 3.2v4 kernel is compiled with the 3.2v2
Dev Sys compiler, so if you compile a SCSI device driver using the
3.2v4 DS compiler, you're in for a nice surprise.

Of course there is a workaround, just by explicitly inserting a
pad byte into the structure before the scsi_cdb union will solve this
particular case.  But how many other similar situations are there?

I don't know if there is an ANSI standard or somesuch that dictates
the correct compiler behavior in this scenario, but SCO has definitely
introduced an incompatibility between the cc compiler between 3.2v2 DS
and 3.2v4 DS.

Just thought I'd make everyone aware of this... I found out the hard
way.

-Ti
-- 
    ///  Ti Kan                vorsprung durch technik
   ///   AMB Research Laboratories, Sunnyvale, CA. USA
  ///    ti@amb.org
 //////  ...!{decwrl,synopsys,tandem,tsoft,ultra}!sgiblab!bazooka!ti
///      ...!{uunet,sun,apple,sco}!altos!bazooka!ti
Xref: sparky comp.unix.sys5.r3:193 comp.unix.pc-clone.32bit:1031 comp.unix.sysv386:17733
From: zeke@fasttech.com (Bohdan Tashchuk)
Newsgroups: comp.unix.sys5.r3,comp.unix.pc-clone.32bit,comp.unix.sysv386
Subject: don't post to comp.unix.sysv386
Summary: obsolete newsgroup
Date: 11 Jan 93 08:58:16 GMT
Article-I.D.: fasttech.1993Jan11.085816.25251
Organization: Fast Technology   Beaverton, OR

I recently tried to help answer a question about tape performance in ISC
unix 2.0.2. The question was originally posted to comp.unix.sysv386, but
not to either of comp.unix.sys5.r3 or comp.unix.pc-clone.32bit.

My reply added group sys5.r3, but also included sysv386, along with a plea
not to post there.

Various followups have observed that sysv386 is still very active. This
is true, but two groups have been created to supercede it. One followup
suggested changing the active file field to =comp.unix.pc-clone.32bit,
but I've also seen ISC discussion in sys5.r3.

Here is a short summary of the various groups:

old:	comp.unix.sysv386	Versions of System V (not Xenix) on
				Intel 80386-based boxes.

new:	comp.unix.pc-clone.32bit	UNIX on 386 and 486 architectures.
	comp.unix.sys5.r3		Discussing System V Release 3.

Given the names of the two new groups, it's likely that ISC questions
will be posted to either or both. This is something we will probably
have to accept.

But that still means that sysv386 is obsolete. No sense in having a THIRD
group for ISC discussions.

I'd like to suggest:

	don't post to comp.unix.sysv386

	if you want to reply to someone who posted to comp.unix.sysv386,
	reply only with a post similar to:

		look for your answer in comp.unix.sys5.r3
	or	look for your answer in comp.unix.pc-clone.32bit

	or send mail telling the poster where to find his answer

	someone should volunteer to post an FAQ type announcement to
	sysv386 about its obsolesense, perhaps monthly, until traffic
	dies down
	
There is no reason to continue sysv386. If we all stop responding there,
it will wither away. The alternative of aliasing into another group
doesn't appeal to me, since it means that old group names never die,
and don't even fade away.
Newsgroups: comp.unix.sys5.r3