这篇文章主要针对提供正式开放的游戏，如果你
  只是在单机游戏上玩一玩，请不要费神阅读，因
  为这对你毫无用处。 
  前一段时间经常看到什么 mud 被黑，某某自称
  “黑客”者要挟某游戏之说，由此产生感慨写下
  这篇文章。这里无意贬低任何人的能力，如果您
  真是一位高手而并非一知半解的翻翻安全公报、
  在网上找点所谓“黑客工具”试试的那种，鄙人
  愿意随时怀着敬仰的心情聆听您的教诲。 
  既然是漫谈，就是想到哪说到哪，内容难免有离题
  之处。 
  有些人采用正式开放的游戏里不设巫师，而启动另
  一个游戏的副本来开发以为就万事大吉了，或者我
  根本不给巫师提供 edit，首先不说这完全抛弃了
  LPMUD 的优越性，还不如改动一下将 OS 和 LIB
  编译后运行，还能极大的提高效率，如果开发环境
  本身是一个不安全的环境，又有谁能保证从这里拿
  走的代码是安全的呢。可能会有人说：比如我根本
  不招收巫师、我们游戏的巫师一生一世都能团结一
  致的象一个人、用人不疑疑人不用，我们的机器是
  请专家配置的，你算什么，等等超过 100 条理由
  来反驳对安全措施的看法，对此我不提出任何意见，
  记得有人说过一句笑话：使服务器最安全的方法就
  是拔掉网线。对于无谓的争论我不感兴趣，如果你
  认为安全是一个不值得一提的话题，请立刻停止阅
  读本文章以免耽误宝贵的时间。 
  最初接触 LPC 就是看的 es2 的 MUDLIB，还是 big5
  码的，读完以后对于其作者 Annihilator 充满敬仰
  之情，虽说是一个“游戏”之作，但绝对只有本着严
  谨的治学态度才能写到这种程度，虽说也存在着不少
  问题，但那都是细枝末节。es2 的 mudlib 由于是一
  个人由一个统一的思路指导创作而成，其明晰整洁的
  模块化结构，科学直观的继承关系，极大的简化了区
  域编程的难易程度和给与极大的灵活性，致使以后的
  文字 mud 在 es2 的沃土上迅速的繁衍生息，而将
  es2 类的 mud 推上 LPMUD 的主流地位，里面有很大
  的必然性。 
  *** 先从 mudlib 内部入手 *** 
  首先要注意几个特别的文件 
  第一位的就是 MASTER_OB ，一般位于 /adm/obj/master.c
  所有限制都是由这个物件里的函数通知 mudos，
  当然也包括读、写的禁止与允许，一般的 mudlib
  都把有关安全的部分集中到一个叫 SECURITY_D 模块里
  统一管理，一般位于 /adm/daemons/securityd.c，
  将 MASTER_OB 的读写判断用 call_other 方式
  引用到这个物件里。这两个文件如果有机会被改写，
  会将 mudlib 的安全机制完全打破，所以在正式运行
  的游戏里应当禁止对这两个文件的写，需要对这两个
  文件进行改写的机会是很少的，如果遇到这种需要
  可在 shell 里进行。 
  巫师列表文件，一般为 /adm/etc/wizlist ，这个文
  件里保存了所有巫师的列表和对应的等级，对这个文件
  的写应当设定成只有 SECURITY_D 物件允许，其它物件
  一律不允许。 
  提升巫师命令，一般叫 promote ，位于 /cmds/arch/
  目录下，（这个命令里应当注意的基本原则例如传入物件
  应当为 this_player(1)，提升的等级不可超过命令执行
  者的等级等基本问题你应当非常熟悉，此文章的其它部
  分也假设你对一些基本的问题已经有了透彻的了解，而
  不会再与提及，如果你未能了解，请立刻停止阅读本文
  章，以免造成不应有的误解而适得其反。）此文件一经
  写好应当不需要再更改，因此在 mudlib 应当禁止对此
  文件的写。promote 需要呼叫 SECURITY_D 里的相应函数
  实现巫师等级的提升，一般为 set_status() 函数，这个
  函数里应当首先判断他的前物件 previous_object(0)
  是否为 fin