53 lines
1.9 KiB
Plaintext
53 lines
1.9 KiB
Plaintext
|
|
UNGUARDED(1) UNGUARDED(1)
|
|
|
|
NAME
|
|
unguarded() - calls a function relying only on the
|
|
object's security
|
|
|
|
SYNOPSIS
|
|
mixed unguarded(function f)
|
|
|
|
DESCRIPTION
|
|
This function allows an object to make a function call
|
|
based solely its own access. Normally, when an object
|
|
makes a function call, the access of all objects invloved
|
|
in the object chain are checked to see if there is proper
|
|
access. For example, if you have a guild object which
|
|
needs to read a help file in your home directory, under
|
|
normal circumstances this will fail. Even though your
|
|
guild object has proper permissions to read your files,
|
|
the person executing the command does not. So, the guild
|
|
object passes the security check, the player fails. Since
|
|
the player fails, the entire read fails. This system is
|
|
useful for preventing people from using other objects to
|
|
gain illegal access. However, in the case outlined above,
|
|
this can be a pain. The unguarded() function call directs
|
|
the mudlib only to check to see if your guild object has
|
|
the proper permission. The argument to unguarded() is the
|
|
function to be called.
|
|
|
|
EXAMPLES
|
|
In the above example, there would be code like this:
|
|
|
|
int cmd_help(string str) {
|
|
if(str != "guild") return 0;
|
|
txt = unguarded((: read_file, HELP_FILE :));
|
|
message("help", txt, this_player());
|
|
return 1;
|
|
}
|
|
|
|
The function unguarded((: read_file, HELP_FILE :)) acts
|
|
just like read_file(HELP_FILE) except that the security
|
|
only checks your object with the first call, but checks
|
|
all objects in the call stack on the second call.
|
|
|
|
LOCATION
|
|
/secure/sefun/security.c
|
|
|
|
Author
|
|
Descartes of Borg
|
|
|
|
1
|
|
|