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

Re: [SERVER] LambdaMOO 1.8.x feature wishlist

At 02:50 AM 11/11/96 PST, Michael Brundage
<brundage@laurel.ipac.caltech.edu> wrote:

>(1) Security.
>
>     Limit string and list lengths to prevent malicious programmers
>     (or unfortunate accidents) from bringing down any MOO currently in 
>     existence.

A list depth limit also make sense if this were to be implemented.  Perhaps
a max size on the amount of memory a value takes up, rather than a max length.

I don't really like this idea tho, since I don't want to have to calculate
how large my lists are going to get before I start creating them.  And of
course, you'd have to allow wizard override of this, but that doesn't fix
the "accident" problem.  This will just be one more thing that needs to be
taken into account when porting code; will the lists that this ported code
from YMOO create fit into the size allowed on XMOO?  You'd have to set it
relatively large in order to get it to not max out on some of the relatively
smaller operations, but then this goes against having this limit in place in
the first place.

I don't see this as a way to fix this "malicious programmer"/"accident"
problem. I could easily work around this limit.  Code that, say, raised
E_QUOTA, when a value got to large could put some objects/the database in an
inconsistant state (of course, this is what try/finally is for, but I don't
want to wrap everything in a try finally for when my variable's sizes reach
the limit. :) ).

Please make this limit optional.

>(3) Customizable exceptions/error handling.

I see the power of that, but what difference does it make what values the
server raises for exceptions, especially if you are going to have it raise
something described as *.divide_by_zero (no matter what value exists in that
prop), which is really what E_DIV is saying anyway.  What do you suggest is
raised when read() is tried on a closed connection with no pending lines?
.connection_closed_and_no_pending_input?  E_INVARG says this.  Apparently,
this is the only time E_INVARG is raised, so it has an unambigious meaning
in terms of read().

I agree though, some bf's, perhaps open_network_connection, could provide
more description as to what the error was (not that it matters, since if it
couldn't open the connection, the error raised described what is wrong.

Is this an attempt to get rid of code like:

  try
    x = open_network_connection(..);
  except (E_PERM)
    return notify(who, "not allowed to make connections");
  except (E_QUOTA)
    notify(who, "not enough resources... trying again in a few mintues");
    fork (60) this:(verb)(@args); endfork return;
  except (E_INVARG)
    return notify(who, "they didn't want our connection :(");
  endtry
  try
    try
      line = read(x);
    except (E_INVARG)
      return notify(who, "nothing to read from connection");
  finally
    return boot_player(x);
  endtry
  return boot_player(x);

and instead do something like this:

  try
    try
      x = open_network_connection(...);
      line = read(x);
    except ($exceptions.permission_denied)
      return notify(who, "not allowed to make connections");
    except ($exceptions.out_of_resources)
      notify(who, "not enough resources... trying again in a few mintues");
      fork (60) this:(verb)(@args); endfork return;
    except ($exceptions.connection_denined)
      return notify(who, "they didn't want our connection :(");
    except ($exceptions.no_pending_input)
      return notify(who, "nothing to read from connection");
    endtry    
  finally
    boot_player(x);
  endtry

Essentially wrapping all the main body of code in one try/endtry? Mmh...

Andy.
Home | Subject Index | Thread Index