Re: $server_options:protect_whatever

• Date: Thu, 21 Dec 1995 12:26:56 PST
• From:
  ThwartedEfforts <abakun@scinc.com>
• Content-Type: text/plain; charset="us-ascii"

Judy Anderson <yduj@cs.stanford.edu>, wrote:
>I was chatting with Quinn about my recent mongo edits of the LambdaMOO
>database involving match() (which turned out to be unnecessary as the
>patch was made available earlier than I had believed it would be).  It
>would be cool if, when a builtin is protected by
>$server_options.protect_builtin, it would try to call
>#0:builtin(@args) before throwing up E_PERM.  That way, if one wanted
>to protect something, one would not have to edit the entire database
>first...

A few points to consider/suggestions:

1) if a builtin is called from SYSTEM_OBJECT, then wiz-only permission checks
   (via $server_options) don't take place.  This would make it easier to have
   the server check permissions for an action instead of trying to do it in
   MOOcode.  In other words:

   @program #0:connection_name
   object = args[1];
   verb = args[2];
   code = args[3];
   if ($perm_utils:controls(caller_perms(), object))
     set_task_perms(object.owner);
     return connection_name(@args);
   endif
   return E_PERM;
   .

   would work.
   This allows some other code stack determine only the perms you want, without
   have to code the permission checks that the server handles into your code
   also.  This comes in handy for things concerning the (read|set)ability of
   objects/verbs/props.  
   We can assume SYSTEM_OBJECT is secure, right?

2) That the verb on SYSTEM_OBJECT that is called be named "bf_" + the name
   of the builtin, to better distinguish between verbs that are handlers for
   builtin functions and those that are server verbs (ie do_login_command).
   Perhaps "secure_" + builtin name to signify that it's only called when
   a $server_options perm check fails.
   This also keeps #0:recycle for it's intended purpose.

3) Probally assumed, but I want to say it: The return value from
   #0:(bf_builtin) be the result of the bf call.  If it returns an value of
   type ERR, then the server would either raise the error or return it
   (depending on the d-ness of the calling verb).  Weither this is an issue
   in later versions (where the d flag is removed or not) is up in the air.

4) caller_perms() in #0:(builtin) be the perms of the verb that made the 
   bf call to begin with.

5) This one is *very very very iffy*: $server_options.builtin_handler be the
   object that has these verbs defined on it that get called if the bf is 
   protected, defaulting to SYSTEM_OBJECT.

Just wanted to bring everyone up to speed, since a similar topic has been
mentioned before.

Andy

• Prev: $server_options:protect_whatever
• Next: -d verbs causing tracebacks
• Index: MOO-cows
• Thread: MOO-cows