# Security

Judy Anderson (yduj@cs.stanford.edu)
Sat, 23 Mar 1996 22:14:56 PST

- Messages sorted by:[ date ][ thread ][ subject ][ author ]

       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