# verb protection

"Adams, Charles" (cadams@msgate.litc.lockheed.com)
Thu, 3 Oct 1996 06:57:00 PDT

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

    >>>>>
    Why can't you say "if (0) pass(@args); endif" to get around the restriction?

    You'd have to do sooo much work to determine whether it was just a "minor"
    change or whether it was really an attempt to bypass security.

     -manta
    <<<<<

    Because once you called set_verb_code() to get around it, the code would
    read "pass(@args);  if(0) pass(@args); endif"

    But I have one suggestion and one comment:

    suggestion:  make the inserted code "return pass(@args);"
    Otherwise, you nuke the return value you probably wanted.

    comment: it's been done.  E_MOO and TecfaMOO have "blocked" methods
    ("method"=="verb", long story behind the choice of terms) , done completely
    in-db with wrappers to add_verb(), delete_verb(), set_verb_info(), and
    verb_info().  It looks like another permission bit -- "b".

    The way it works is that any parent blocking a method (@chmod foo:bar +b)
    prevents the method from being added anywhere below it except by the owner
    of the original blocked method or with wizardly perms.  Existing methods are
    unchanged (so one should make sure it hasn't been overridden already before
    blocking it).  However, no existing method may add any alias that matches
    any alias of a blocked method above it (standard wildcard matching applies).
     Anywhere it is overridden and is !b (normal, unblocked), all its
    descendants become unblocked as well.  One can unblock individual aliases
    this way.

    It's also the model for a an in-server version, which also uses permission
    bits (including an E_MOO compatibility mode using +/-b, thanks!)  If the
    author of this server patch could pipe up (I forget who you are!) and
    announce it, please?