MOO-cows Mailing List Archive
[Prev][Next][Index][Thread]

IMPORTANT LambdaMOO patch release 1.8.0p4

I have released version 1.8.0p4 of the LambdaMOO server to the usual place:

	ftp://ftp.parc.xerox.com/pub/MOO/LambdaMOO-1.8.0p4.tar.Z

This is a very nasty bug-fix release.  I mean that both ways: both the bug and
the release are nasty.  PLEASE READ the following change-log entry very
carefully if you are currently running a server of versions 1.8.0 through
1.8.0p3.  I'm sorry the entry is so long and messy, but this one was a pretty
nasty screw-up on my part.

	Pavel

Here's the ChangeLog.txt entry:
-------------------------------------------------------------------------------
Version 1.8.0p4, 18 April 1996
-- Fixed potential memory-smash bug in the parsing of a misplaced `$'
   expression.  (Thanks to Brack for reporting this.)
-- Fixed odd choice of errors raised by chparent(A, B); it used to raise E_PERM
   when A was not valid or B was neither valid nor equal to #-1.  It now raises
   E_INVARG in these cases.
-- Fixed *really* nasty bug in the way the $bf_FOO() overrides for protected
   built-in functions were implemented.  The first (and least nasty!) effect
   was a potential memory smash and/or server panic if you killed a task that
   was in the middle of a call to some $bf_FOO().  (Thanks to slayer@kaiwan.com
   for reporting this effect of the bug and thereby ruining the rest of my day,
   spent tracking down and trying to cope with the *rest* of the effects.)  The
   more subtle and terrifying effect is given below.
   ********** There was a serious bug in versions 1.8.0 through 1.8.0p3 of the
   ** NOTE ** server that could cause a database written by such a server to be
   ********** read back in incorrectly and, in some cases, *undetectably*,
   causing one or more bad effects outlined below.  One of the potential
   effects, perhaps the most serious one, *is* detectable and fixable; release
   1.8.0p4 of the server detects and fixes this problem during loading.  If it
   discovers/fixes an instance of the problem, it also prints a warning message
   into the log.
   ----------------------------------------------------------------------------
   NOTE PLEASE: As described below, most databases will NOT be at risk from ANY
   of the potential problems.  I only describe them in this much detail to make
   sure that all POSSIBLE cases are disclosed.
   ----------------------------------------------------------------------------
      In a nutshell, the problem is that the server can write out a database
   file that, on reloading, makes it look as if an overridden built-in function
   (i.e., one that is made wiz-only by a $server_options.protect_FOO property
   and then overridden by a $bf_FOO() verb) *made a verb call* to $bf_FOO()
   instead of being *replaced* by that verb.  This would be in the saved state
   of some task that was suspended at the time the database file was written.
   This means that, after the task resumes and the call to $bf_FOO() returns,
   the built-in function implementation could be re-entered in a very confused
   state.  This confusion could have the following effects:
	1) A function that never actually calls a verb (i.e., almost any of the
	   current built-in functions) could mistake $bf_FOO()'s returned value
	   for an argument list and smash memory all over the server.
	   (Fortunately, this is the detectable and fixable case mentioned
	   above; therefore, this effect cannot happen under 1.8.0p4.)
	2) The eval() function could end up wrapping an extra {1, ...} around
	   the correct returned value.  That is, instead of returning {F, V} as
	   it should, it would return {1, {F, V}} in this case.
	3) The create() function could return a different object number from
	   the correct one; in particular, it could return an invalid or even
	   negative object number.
	4) The recycle() function could recycle the wrong object, without
	   checking permissions and without calling that object's :recycle
	   verb, and/or leave the correct object unrecycled.
	5) The move() function could move the wrong object to the wrong
	   destination and/or leave the correct object where it was.
   If you reboot your server under 1.8.0p4, I believe that effect (1) above is
   completely prevented and that, in effects (4) and (5), the function in
   question is extremely unlikely to operate on the wrong object.  If you are
   actually at risk from any of these effects (see below), then by far the most
   likely cases are as follows:
	1) Not possible.
	2) The eval() function will have the full effect given above.
	3) The create() function will have the full effect given above.
	4) The correct object will not actually be recycled, even though its
	   :recycle verb will have been called.
	5) The correct object will not actually be moved, even though the
	   destination's :accept verb will have been called.
   >>> NOT ALL DATABASES ARE AT RISK FROM THESE EFFECTS <<<
      For a database to be at risk, all of the following must be true:
	a) One or more of the functions eval(), create(), recycle(), or move()
	   must have been made wiz-only via the $server_options.protect_FOO
	   property, for the appropriate FOO.
	b) Such a function must have been overridden by a $bf_FOO() verb.
	c) It must have been possible for the code of the $bf_FOO() verb (or
	   any code it calls) to call suspend().
	d) The database file must have been written to disk (i.e., either via a
	   checkpoint or a shutdown or a panic) during the time that (a) and
	   (b) were true and while the call to $bf_FOO() was suspended.
	e) You must be restarting your server from the database mentioned in
	   point (d).
   Even in a database that is at risk, it is only at risk for the effects of
   the specific function(s) for which all of points (a) through (e) are true.
   For example, if you have never protected and overridden the move() function,
   then your database is not at risk for effect (5).
     These facts imply that, if your server might be at risk but is still
   running under 1.8.0p3 or earlier, you may be able to remove the risk before
   shutting down, by making one or more of points (a) through (e) false.  For
   example, you might be able to stop overriding one of the functions in
   question and then wait until there are no longer any suspended tasks inside
   calls to the appropriate $bf_FOO() verb.
      >>> WARNING: Do NOT attempt to kill such a suspended task in order to
		   remove the risk from your system; this would trigger the bug
		   mentioned at the top of this release note, quite possibly
		   panicking your server.
   Naturally, I am dismayed at both the existence of this bug and at the fact
   that I cannot guarantee even those not yet bitten by it that they can avoid
   eventually losing.  This is the first time I can recall this sort of thing
   happening in the entire time LambdaMOO has existed.  Just my luck, just as
   I'm about to retire... :-(
-------------------------------------------------------------------------------
Home | Subject Index | Thread Index