Re: verb protection

• Date: Thu, 3 Oct 1996 06:00:03 PDT
• From:
  Richard Godard <janus@cam.org>
• Cc: moo-cows@parc.xerox.com
• Content-Type: text/plain; charset="us-ascii"
• In-Reply-To: <Pine.GSO.3.95L.961003010639.22042B-100000@unixs1.cis.pitt.edu>

At 0:24 -0500 10/3/96, James R O'Kane wrote:
>I was thinking today during a boring calc recitation about ways to keep
>people from over-riding verbs that i didn't want them to. and i came up
>with 2 possiblilities..
>
>both involve adding props similar to the $server_options.protect_foo where
>it's .protect_verbname.
>
>the first way would involve editing $add_verb and/or $bf_add_verb to
>return E_PERM if .protect_verbname exists and is true and player !=
>wizard.
>
>the second way is to have set_verb_code add a pass(@args) to the verb at
>compile time, if it can't find it in the verb already..

... my_stuff ...
raise(E_SECURITY_HOLE, "Verb overriden.") && 0 && pass(@args);

>i see pros and cons to both ways.
>pros to way 1: it gets the job done and seems to be the easiest.
>cons to way 1: it stops people from making _any_ additions down the line
>with out wizperms..even if they plan to use pass()
>
>pros to way 2: it allows people more freedom to add verbs as they choose
>and pass(@args) is always called.
>cons to way 2: it'll be a bit tick heavy to search for any pass()'s in the
>verb and it kinda produces random results if programmers forget that
>pass() is added.
>
>anyone have any thoughts on the matter?
>i think this has come up before, but the list has grown quiet..:)

I guess it depends what you plan to use the non-overridable verbs for as
well as who will be allowed to make their verbs non-ovveridable.

If you plan to use your verb for anything secure, #2 is NOT the way to go.

I implemented non-overridable verbs for the masses (i.e. any proggie can
make their verbs non-overridable if they needs to) Then I made :initialize
non-overridable on $object (a parent of any objects that had #-1 as a
parent (i.e. had no parent)) and then renamed non-wiz versions of
:inititialize to :custom_initialize and made sure all (but the one on
$object) the :initialize verbs pass(...)

Now $bf_create call object:initialize() and then object:custom_initialize()

That way I have a secure initialization (wiz ought to know what they code)
and then programmers can initialize descendants of their generics through
:custom_initialize without possibly interfering with the vital part of the
initialization.

Back to the original question:

>cons to way 1: it stops people from making _any_ additions down the line
>with out wizperms..even if they plan to use pass()

If you make a verb non-overridable it's that you don't want it to be
ovveriden, if you still want programmers to do some complementary work,
call a custom non-blocked verb when you are done with calling your
non-overridable verb.


I hope this help.

-- Richard

• verb protection
• From: "James R O'Kane" <jrost10+@pitt.edu>

• Prev: Re: verb protection
• Next: Re: verb protection
• Index: MOO-cows
• Thread: MOO-cows