[Prev][Next][Index][Thread]

# Re: $server_options:protect_whatever

- Date: Thu, 21 Dec 1995 12:26:56 PST
- From:
- 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

Home | Subject Index | Thread Index