# How to fix #2 as all powerfull :) and other kiddies stories :)

Roger Crew (rfc@microsoft.com)
Tue, 14 Nov 1995 06:23:45 PST

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

    >  What I need here is a way to make #2 non-bootable and non-newtable ect..
    >  there is no way to kick him off cept to edit the DB or shut the moo down..
    >  anyone know of such a way..

    There really isn't.

    Consider that the normal logout procedure is for the
    player to boot himself.  Now you can certainly hack the server to make
    #2 unbootable (see boot_player() in server.c), but this will also
    make it impossible for #2 to disconnect of his own accord, unless you were
    to also put in a task_perms() check to make it possible for #2 to boot himself,
    but you need to do this in a way not spoofable by other wizards.
    The best I could see along these lines is something to check that the current
    task is indeed a command task (so that we can't fake it out with FORK),
    and that the top-level `player' for that task is indeed #2 before allowing
    boot_player(#2).

    Consider also that it may be necessary from time to time for #2 to be able
    to reconnect (e.g., window or tinyfugue or emacs session gets hosed in some
    way).  Again, another wizard can always do `;#2.password=crypt("secret")'
    and then immediately connect as #2, blowing off the real #2.
    Rewriting #0:do_login_connection/$login:connect to treat #2 special won't work
    since another wizard could likewise put in his own version of these verbs.
    Again, you'd have to find a way to block this at the server level
    (e.g., by hardwiring a password into the guts of do_login_task() in tasks.c)

    While this is all doable in principle, it is of dubious utility,
    since, while your rogue wizards could indeed be prevented from
    booting/reconnecting you, they'd still have free reign over everything else.

    Or were you planning to sit at the console
    with your finger on the shutdown() switch 24 hours/day?

    If you were relying on #2 being connected for logging purposes,
    you'll want to know about the `server_log()' builtin, which takes
    a string argument and prints an arbitrary message to the server log;
    you should be using that instead of `notify(#2,...)' for anything
    you care about.

    The best solution to the rogue wizard problem is to NOT MAKE THEM WIZARDS
    IN THE FIRST PLACE, or, barring 20/20 hindsight, to take away their wizard
    bits at the first hint of rogue activity (and then SCOUR your db,
    if these were folks with any kind of a clue...)