# Means of gathering data

Michael Moore (mike@mail.datasys.net)
Fri, 14 Jun 1996 13:20:03 PDT

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

    Gustavo Glusman wrote:

    > Then, once somewiz tells him/her something, the programmer owns a suspended
    > task for which player.wizard is true. Next thing the programmer has to do
    > resume() that task, passing it suitable arguments, e.g. {your-recorder,
    > "start", {}}.
    > There are simpler ways, but this one gives an idea of how such a malicious
    > programmer could keep one or many such tasks, to be used at will later on,
    > e.g. when said wizard is not online anymore.

    Yech, you're absolutely right.  Time to '@grep player.wizard' and repair
    sloppiness in my thinking.  Diverting verb calls like that never occurred
    to me.  For normal generics, I use $perm_utils:controls (caller, this) but
    for most of my wiz stuff I thought player.wizard to be adequate.  Ironic, eh?
    :)

    Thank you for pointing this out to me, and if you could point me in the
    direction of those MOO security documents I would very much like to have a
    look at them.  The MOO I'm a wiz on is small, everybody knows everybody else,
    but we're starting to grow...

    While we're on the subject, I have an interesting question.  'player' will
    revert to its initial value in the calling verb when the calling verb is not
    running with wizard permissions.  What happens if a wiz-owned verb changes
    player, sets task perms to non-wizard, then calls another verb?  Will 'player'
    stick to the value set when the task had wizard permissions, or will it revert
    to the inital value of player in the original verb, because the task didn't
    have wiz perms when it made the new verb call?

    I know the answer to this with respect to LPMOO.  On LPMOO, which simulates
    1.7.8 of Lambda, player will be reset because the task had no wizard perms
    when the new verb call was made.  How does it work in Lambda 1.7.8?  1.8.0?

    LPMOO simulates some things about Lambda incorrectly--the order of objects in
    connected_players() for example and where property permissions are cloned from
    when creating new objects.