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