# Production release 1.8.0 of the LambdaMOO server

Roger Crew (rfc@microsoft.com)
Mon, 11 Mar 1996 19:22:48 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

    just noticed this...

     -- Verbs defined on #0 are no longer subject to the wiz-only
    permissions check
        on built-in functions generated by defining
    $server_options.protect_FOO with
        a true value.  Thus, you can now write a `wrapper' for a built-in
    function
        without having to re-implement all of the server's built-in
    permissions
        checks for that function.  (Thanks to ThwartedEfforts for bringing
    this idea
        back to my attention.)

     -- If a built-in function FOO has been made wiz-only (by defining
        $server_options.protect_FOO with a true value) and a call is made to
    that
        function from A NON-WIZ VERB NOT DEFINED ON #0 (that is, if the
    server is
                      --------------------------------
        about to raise E_PERM), the server first checks to see if the verb
    #0:bf_FOO
        exists.  If so, it calls it instead of raising E_PERM and returns or
    raises
        whatever it returns or raises.  (Thanks to yduJ and ThwartedEfforts
    for
        putting this idea together.)

    reaction:  AAAAAAAAAAAAAAAAAAAAARRRRGGGHHH!
    If you must do something like this I would MUCH prefer the following:

     -- If a built-in function FOO has been made wiz-only (by defining
        $server_options.protect_FOO with a true value), and a call is made
    to that=20
        function from ANY VERB NOT DEFINED ON #0,
                      =3D=3D=3D ----------------------
        the server first checks to see if the verb #0:bf_FOO exists.
        If so, it calls it (REGARDLESS OF THE PERMISSIONS OF THE CALLING
    VERB).
        If not, E_PERM is raised if the calling verb is nonwizardly
          (i.e., same behavior as before if #0:bf_FOO doesn't exist).

    The problem with the previous version is if I'm looking at some random
    verb in the db and I see a call `create(...)', given that #0:bf_create
    could do completely arbitrary things, I have NO IDEA what this call is
    going to do unless I know the wizardliness of the verb. =20

    An underlying principle here should be:

      A verb should have the same semantics regardless of its permissions.

    By semantics, I mean the sequence of actions it attempts to perform on
    the db, property-writes and verb calls in particular.  The only
    difference that should be made by changing the ownership of a verb to be
    wizardly/nonwizardly is that in the nonwizard case there is the
    possibility of it bombing out somewhere in this sequence of actions with
    E_PERM.  In particular, a builtin function should not engage in an
    entirely different sequence of actions if the verb is/isn't wizardly.  I
    realize that

    (1)  There does exist one builtin function (queued_tasks()) that behaves
    slightly differently depending on whether it is wizard-called or not.=20
    This is a mistake from prehistory that has thus far been confined to
    this one function.

    (2)  Yes, it is possible to write verbs that explicitly depend on
    caller_perms().  I maintain that it is bad style to use caller_perms()
    for anything other than a permission check, i.e., to raise(E_PERM) or
    return some appropriate failure value if caller_perms() aren't right,
    otherwise continue.  I'll grant that one can't force people to use good
    style, but if even the builtin functions don't behave this way, this
    removes any possibility of getting the rest of the db to behave this
    way.

    Note that if you want to have a raw version of a given callable from
    arbitrary wizard code on other objects, my proposal still allows you to
    define such a version on #0.  The difference is that it will now be
    apparent from examination of said code which version of the builtin was
    intended.  E.g., `$create(...)' is always the raw version while
    `create(...)' is always #0:bf_create. =20

    While I'm still slightly bothered by having verbs on #0 behave
    differently, this is a lesser evil in that
      (*) all of the weird #0 verbs will still be in one place
      (*) #0 is already treated specially by the server in so many other
    ways
      (*) the fact that I'm editing #0:foo is usually in a prominent place
          (e.g., emacs buffer name); the fact that the verb is wizowned=20
          generally isn't, though I'll grant that this is a client issue.
    =00