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

RE: Production release 1.8.0 of the LambdaMOO server

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 
    function from ANY VERB NOT DEFINED ON #0,
                  === ----------------------
    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.  

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. 
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.  

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 
      generally isn't, though I'll grant that this is a client issue.
Follow-Ups:
Home | Subject Index | Thread Index