Security

• Date: Sat, 23 Mar 1996 22:14:56 PST
• From:
  Judy Anderson <yduj@cs.stanford.edu>
• cc: moo-cows.PARC@xerox.com
• In-Reply-to: "Jacqueline Hamilton's message of Sat, 23 Mar 1996 17:52:44 PST <Pine.HPP.3.90.960323193938.17190A-100000@fohnix.metronet.com>"
• Posted-Date: Sat, 23 Mar 1996 22:14:56 -0800 (PST)

   Date: Sat, 23 Mar 1996 17:52:44 PST
   From: Jacqueline Hamilton <kira@metronet.com>

   > Stock players shouldn't be able to @chparent themselves, that is a verb
   > left to $builder.  make sure that new players are kids of $player, and not
   > $builder.

   Actually you may need to modify #4:@chparent, because a non-builder can 
   still do something like '@chparent me to #4' and have it work.  At least, 
   this was true on older cores; I've not tested it with a more recent core.

I just looked at LambdaCore @chparent, expecting to see it not let you
use @chparent if player != this (which is the case only if the player
does not have direct access to @chparent, and is having the server
match it on iobj).  However, I didn't see this.  It's quite likely
that this security check should be installed, and I may just do it.
Simply change:

 6:  elseif (this != player && !$object_utils:isa(player, $player))

to 

 6:  elseif (this != player)

Changing the error message to the truth would be a bonus as well.
E.g. player:tell("@chparent not available to your player class.")

      Judy Anderson yclept yduJ          'yduJ' rhymes with 'fudge'
 yduJ@cs.stanford.edu (personal mail)   yduJ@harlequin.com (work-related)
	Join the League for Programming Freedom, lpf@uunet.uu.net

• Re: Security
• From: Jacqueline Hamilton <kira@metronet.com>

• Prev: Re: Security
• Next: Re: Security
• Index: MOO-cows
• Thread: MOO-cows