[Prev][Next][Index][Thread]

# Re: [SERVER] LambdaMOO 1.8.x feature wishlist

- Date: Mon, 11 Nov 1996 13:37:31 PST
- From:
- Content-Type: text/plain; charset="us-ascii"

    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.

- Prev: Re: [SERVER] LambdaMOO 1.8.x feature wishlist
- Next: Re: [SERVER] LambdaMOO 1.8.x feature wishlist
- Index: MOO-cows
- Thread: MOO-cows

Home | Subject Index | Thread Index