[MUD-Dev] Re: Issues from the digests and Wout's list

[clawrenc at cup.hp.com]

In <3360B856.167EB0E7 at iname.com>, on 04/25/97 
   at 08:25 PM, Shawn Halpenny <malachai at iname.com> said:

>clawrenc at cup.hp.com wrote:

>> A key point in my game is free user programming.  While there are
>> always security questions of "real" vs "newly user programmed"
>> objects, more or less I allow any user to program any type of object
>> or feature at any time.  The security features then just ensure that
>> he can't program up a 50,000hp wet noodle to defeat the red dragon
>> (well, actually he can program such a weapon, its just that
>> unvalidated user-programmed objects can't affect validated objects
>> (like the red dragon) in that way).

>I'd first encountered this free user programming idea when I came
>across a post of yours on the ng's.  Could you dispense a smidge of
>the fundamentals so I know what your approach is about?  

Base principle:  The server shall expressly support the fact that any
user at any time can program any new object with any feature set.

Base rule:  The programming of any feature on any object shall not
require source access to any other object(s).

Caveat to principle: The user's capabilities can be degraded, turned
off, or otherwise restricted by the admins.

The principle pretty well aligns with many MOO and Tiny-* systems. 
LambdaMOO being a good case in point.  The rule however seperates me
from the rest of the crowd and is a fundament of my security design.

The other trick is mixing all this with a goal oriented game.  If
Bubba is able to program up a 50,000hp mega wet noodle at a moments
notice, how do you maintain game balance for the near-unkillable red
dragon?  I manage this end thru security.

>I've got a
>notion in mind, but I'd rather know where you're coming from before I
>make assumptions.  From what I've thought about it, I was wondering
>how "free" it can be.  

Compleatly and utterly free.  I do *NOT* restrict what users can
program.  What I do restrict is how the objects they program can
affect their environment.

>Now you say that unvalidated user-objects
>can't affect validated objects (sensible).  Does that mean that every
>object the user programs has to be run by an admin before it is
>allowed in the game?  Or is there a set of "safe" constructs that
>anyone can use and objects using only those have no need for
>validation?  

Nope. 

My base security model derives from CoolMUD with a few extensions of
my own.  Essentially, every object vets its own security.  Each
individual object deides what messages it will accept, from whom, and
how or even if it will respond.  Adittionally each method on each
object similarly controls and vets what messages it will accept yada
yada.  

The base security API's are accept() and reject().

Accept() takes two arguments, the ObjectID in question (usually the
originator of the message, but can be anything), and a list of
ObjectIDs.  Accept() will raise ERR_REJECTED exception if the
inheritance tree of the first object does not intersect any of the
objects listed in the second argument.  Reject() operates identically
except that the exception is raised if the object's inheritance tree
does intersect the list.

Every object has a postman() method.  The postman() method is
responsible for accepting()ing or rejecting() all messages that arrive
at an object.  Many methods in their agument validation section also
have accept()/reject() statements to more finely control what objects
they will manipulate.

The other corner of the secutiry triangle rests on the fact that a
child may only inherit from a parent if the parent allows it.  I do
not allow free inheritance.  It is up to the parent to rule whether or
not it will accept tha parent.  Ditto for disinheritance.

How this impacts free user programming is that all newly created
objects auto-inherit from $NEW_OBJECT.  Nobody but an admin can remove
that inheritance ($NEW_OBJECT refuses to release the child).  Objects
can also inherit from $VALIDATED_OBJECT (again, only admins can do
this) if its needed to create an object which is still a $NEW_OBJECT
but needs to be able to do a little more.

This makes it simple for combat code for instance to refuse messages
from $NEW_OBJECTs.  You can club the red dragon over the head all you
want with your newly programmed 50,000hp wet noodle, but the combat
code for the dragon will not allow allow any damage to be levied
against the dragon for each blow.  Note however that you can also
program up a mega-strong dragon of your own (also a $NEW_OBJECT) and
have the above wet noodle be very effective in killing it.

I know this is a frightful abuse of inheritance, but it seems to work.

>This is of interest for me, since I'm embedding a
>language into the world that will allow complete manipulation of all
>aspects of it, and the whole place becomes richer if anyone can come
>along and implement something cool.  

Precisely.

>Security becomes the biggest
>issue, methinks, and with my language (at the moment, I intend to use
>Perl) there are a lot of nasty things users shouldn't do that are
>perfectly legal if you're an admin.

I keep looking at using a pre-existant language for my server, with
PIKE and REXX being the main candidates, but I've yet to find one I
think I could be happy with both for learning curve for new users, and
feature set.

BTW Have you looked at PerlMUD?

--
J C Lawrence                           Internet: claw at null.net
(Contractor)                           Internet: coder at ibm.net
---------------(*)               Internet: clawrenc at cup.hp.com
...Honorary Member Clan McFUD -- Teamer's Avenging Monolith...