MOO-cows Mailing List Archive
RE: How to fix #2 as all powerfull :) and other kiddies stories :)
> 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
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...)
Subject Index |