MOO-cows Mailing List Archive

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

player/caller/callerperms




I thought I might give some overview of various forms of security and which 
ones you might want to use.  Please note that these are all 1.8.0 savvy in 
that they use raise().

If you have any questions or comments and wish a private reply, please 
include your e-mail address in the body of the reply.  I use the Antichrist 
of mailers, MSmail, so every post to moo-cows is from "moo-cows-errors" in 
my mailbox.

All of these checks go at the top of the verb you're coding, or at least 
before anything critical happens.  Comments are optional, I recommend you 
don't actually use them (especially since they'll only work on JHCore and 
E_CORE)

When I refer to a "class owner" below, I'm referring to a person who owns a 
"generic object" that your object is somehow derived from.  On LambdaMOO, I 
am an SSPC (soon to be TUPC) and therefore I have about a dozen parents of 
me, going from SSPC (owned by Sick), down several levels to Politically 
Correct Player Class (Owned by Jay), and so on down to the Generic 
Programmer, Generic Builder, Generic Player ...  Every one of those is a 
parent of me, and therefore the people who own them are my player class 
owners.

Standard task-perms check:
 ------------------------------------------
$perm_utils:controls(caller_perms(), this) || raise(E_PERM);
// If the owner of the verb that called this doesn't control this object, 
raise E_PERM
// ADVANTAGES: extremely secure
// DISADVANTAGES: Only wizards and the object's owner can call it, therefore
//                                             player class owners can't 
call it.  If you override a verb
//                                             a player class adds extra 
features to, you probably lose.

Standard "private method" check:
 --------------------------------------------------
(caller == this) || raise(E_PERM);
// If this wasn't called from a verb defined on this object or a parent, 
raise E_PERM
// ADVANTAGES: allows a class owner to call it
// DISADVANTAGES: If one of your verbs gets hacked, including one defined by 
a
//                                            parent class, you could lose. 
 If you don't trust a parent class
//                                            owner, you definitely lose 
(and you should @chparent)

Ultra-paranoid check:
 --------------------------------
((caller == this) && $perm_utils:controls(caller_perms(), this)) || 
raise(E_PERM);
// This is a combination of the above, and will only let verbs you own
//     (or wizardly ones) that are defined on yourself or a parent call it.
// Generally there's no need for this level of security, and in truth, 
doesn't afford
// much more protection.

Enforce no callers:
 ---------------------------
callers() && raise(E_PERM);
// This one is generally used only by wizards on verbs like 
$server_started(),
//   $user_connected, and so on
// It's also used on some !x verbs just to make sure someone didn't hack 
through
//      somewhere and manage to call it.  Once it's established there are no 
callers()
//      it's safe to do a set_task_perms(player)
// There were once server bugs that allowed a person to completely clear the
//    callers() stack.  These have long since been patched.

+x Command-line verb, wizards only
 -----------------------------------------------------
if (!valid(cp = caller_perms())
   set_task_perms(cp == $nothing) ? player | raise(E_PERM);
else
   set_task_perms(caller_perms());
endif
// If it's called from the command line, runs with the permissions of the 
player who
//   typed it.  If it's called from a verb, run with the permissions of the 
verb that called it.
//  If it's running with the permissions of a programmer that no longer 
exists,
//    raise an error.  You might want to trigger some sort of security alert 
too
//    since verbs belonging to a recycled programmer are bad things indeed.




Home | Subject Index | Thread Index