From: amylaar@mcshh.Hanse.DE (Joern Rennecke)
Subject: Re: Driver additions
Organization: Point of Presence & MCS Hamburg
Date: Tue, 1 Sep 1992 21:38:45 GMT
Keywords: compat-mode, MudOS, CD, standardization, etc.

beeman@cats.ucsc.edu (Adam Beeman) writes:


>In article <1992Aug26.005902.829@engage.pko.dec.com> oakley@contra.enet.dec.com (The Zeeker) writes:
>>
>>	As far as I can see, 2.4.5 IS a standard.  Nice, it works, not
>>	very buggy.  I have yet to see a 3.0 Mudlib in vanilla state
>>	that ACTUALLY WORKS !!  That was the great thing about 2.4.5
>>	Mudlib, you could do whatever you wanted with it.  BUG-FREE!
>>

>	I just sat down and wrote two programs that will run on most
>2.4.5 mudlibs and bring the mud down.  The only thing they need is to be
>loaded.  The first will ask the person who loaded it for the name of
>an admin, then move itself to the admin and use the admin's permissions
>in order to remove player.c, the master object, and all traces of itself.

This is not a fault of the mudlib as a whole. With a decent
master::valid_write() you don't have these problems, while you still have
the option to call player::valid_write() to maintain full compatibility for
legal accesses.

>The second uses its own security system, and handily bypasses the regular
>one by starting a heartbeat and removing all the files in /obj, /room,
>/secure, and any other subdirectories of "/", one directory per heartbeat.

This has been fixed by lars before he left, although a bit cludgy. If
the command_giver was not interactive, all access would be refused in 3.1.2 .
Which was, of course, yet another kind of bug that needed correcting...

>	I haven't tested these yet but I'm pretty confident they should work.
>They basically show that the 2.4.5 standard is totally insecure unless you
>can trust EVERY SINGLE WIZARD on the mud not to write this sort of thing.
>Since I'm generally a nice person until I get stepped on or insulted,
>I'll refrain from posting them (which I was going to do) because I'm sure
>there's a lot of very nice, well-meaning admins of 2.4.5 muds whose work
>I would hate to see go down the drain.

>	As far as the mudlib situation goes, you're absolutely right.
>I certainly wouldn't call the TMI mudlib bug-free, and I don't feel 
>qualified to rate any of the others available.  This is a very odd point
>in the evolution of LPmuds.  For those who want simplicity, stick with
>2.4.5.  But your work may never be ported to a newer, better mud in the
>future.  That's the way it goes.  For those of you who are fed up with

Wrong. You can have continuous evolution, and mix old and new code.

...
>Lars isn't a player in this field anymore; his last driver will be a 
>standard for people who are happy with it.  It's stable, and supports

It's stable unless you try to use the new features or parse_command *chuckle* .

>both compat-mode and native-mode.  MudOS, while still certainly an LP driver,
>(look, we post in rec.games.mud.lp about it!) is an *evolution* of
>Lars' work.  We saw that Lars was slowing down and starting to refuse
>diffs that were being sent to him, and at some point around 3.0.47 or 
>so we just plain gave up sending him our fixes and improvements.

>	We basically had no intention of supporting compat-mode right
>from the start, and eventually we decided to rip it out so that nobody
>would even try to run in compat mode with it and pester us when it didn't work.
>When you're trying to break new ground and make a new system, then
>backwards compatibility is a real handicap; ask the folks at genesis,
>they threw out all their 2.4.5 code and wrote things from scratch just
>as TMI has done.

Backwards compatibility is a challenge to make a flexible driver.

	Amylaar