UNGUARDED(1) UNGUARDED(1)
NNAAMMEE
_u_n_g_u_a_r_d_e_d_(_) - calls a function relying only on the
object's security
SSYYNNOOPPSSIISS
mixed unguarded(function f)
DDEESSCCRRIIPPTTIIOONN
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 _u_n_g_u_a_r_d_e_d_(_) function call directs
the mudlib only to check to see if your guild object has
the proper permission. The argument to _u_n_g_u_a_r_d_e_d_(_) is the
function to be called.
EEXXAAMMPPLLEESS
In the above example, there would be code like this:
iinntt ccmmdd__hheellpp((ssttrriinngg ssttrr)) {{
iiff((ssttrr !!== ""gguuiilldd"")) rreettuurrnn 00;;
ttxxtt == uunngguuaarrddeedd((((:: rreeaadd__ffiillee,, HHEELLPP__FFIILLEE ::))));;
mmeessssaaggee((""hheellpp"",, ttxxtt,, tthhiiss__ppllaayyeerr(())));;
rreettuurrnn 11;;
}}
The function unguarded((: read_file, HELP_FILE :)) acts
just like _r_e_a_d___f_i_l_e(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.
LLOOCCAATTIIOONN
/secure/SimulEfun/security.c
AAuutthhoorr
Descartes of Borg
1