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

• Date: Tue, 14 Nov 1995 06:23:45 PST
• From:
  Roger Crew <rfc@microsoft.com>

>  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...)

• Prev: Re: How to fix #2 as all powerfull :) and other kiddies stories :)
• Next: HUH?? I got a DB.PANIC and this is ther error code. HUH?
• Index: MOO-cows
• Thread: MOO-cows