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