Re: verb protection

• Date: Thu, 3 Oct 1996 06:57:00 PDT
• From:
  "Adams, Charles" <cadams@msgate.litc.lockheed.com>
• Encoding: 37 TEXT

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

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