Subject: on beta-wizards, para-wizards and necromancers

From: Roger Crew <[email-masked]>
Date: Wed, 15 Sep 1993 14:47:45 -0700

[... I was reminded of one of my backlogged postings, this one in
     response to a proposal to introduce "alpha and beta wizards"
     having different different sets of privileges.  Most of the
     responses were correct (IMHO) in that many of the special powers
     that one might want to parcel out to special players
     are best implemented in the db.  However... ]

There *is* a division of powers within wizardom that I believe is
useful to implement in the server and in fact requires (I think)
minimal changes.

Background:
  Once upon a time, I said that one should be extremely wary of wizard
  verbs that call eval() and set_verb_code().  More generally, one wants
  to keep TIGHT control on the ability to create or modify wizard verbs
  --- not necessarily because the wizards are untrustworthy but being
  human, they're forgetful and do silly things from time to time.  With
  a reliable audit trail on the production/alteration of wizard verbs,
  one can quickly answer questions like "Who wrote this sh*t?"

Idea:

  set .programmer=0 on a wizard player and you should get 
  a NONPROGRAMMER WIZARD who can do everything EXCEPT create/modify verbs.

No new flags are needed; we're merely giving meaning to the currently
anomalous situation of an object for which .programmer=0 and .wizard=1.
The new hierarchy goes

   player   
   programmer
   wizard  
   programmer-wizard (if you want to give this a more exciting name 
                      like "necromancer", feel free...)

The only server hacking needed is another 10 lines of code to

  (1) require .programmer=1 && .wizard==1 in order to
     (a) change .programmer or .wizard on any object
     (b) create/modify properties/objects owned by a programmer-wizard
     (c) set_task_perms(<any programmer-wizard>)

  (2) require .programmer=1 in order to create/modify any verbs 
      (the only change from before is to enforce this for wizards).

      In order to make the whole system a little more consistent, I'd
      also suggest that the notion of "modifying verbs" be extended to
      include set_verb_info() and set_verb_args() as well as
      set_verb_code(), but this is a side issue.

Note that making these changes to the server will not break any
existing code since currently all existing wizards are also
programmers.  One may go through at leisure to search for and chown
those few verbs that actually require programmer status and then later
de-programmer most of the wizards.

Why is this useful?

Consider the problem posed by having >1000 wizard owned verbs (the
current situation on Lambda).  If any one of them does something
stupid (e.g., evals a user supplied string with its own perms), the
permissions of that wizard can be usurped.  If however those
permissions cannot be used to alter any existing verbs or install any
new ones, the cracker will (if things are set up right) have much more
work to do to subvert the system.

Note that the vast majority of wizard verbs in LambdaCore exist
for such purposes as getting around restrictions on accessing +c
properties, using builtin functions like notify() and move(), and
utility routines that need to do set_task_perms(caller_perms()).
Very few actually need to create/modify verb code.

Then we would just need a single programmer-wizard, an object for the
programmer-wizard to own and something like 5-10 verbs/properties to
handle the creation of wizard verbs; we can be super-paranoid about
them.  One could, for example, entirely forbid creation/modification
of wizard verbs except via an explict player command from some wizard
(and perhaps even put suitably absurd limitations on the creation of
new programmer-wizard verbs...  "Type the secret prog-wiz password now
(you have 10 seconds): ")

For the remaining 1000 nonprog-wizard verbs one need only
be merely paranoid (some paranoia is called for since non-programmer
wizard verbs can still do things like recycle the db --- admittedly bad, 
but not as bad as being able to subtly pervert it with Trojan horses).

--
Roger Crew
Internet:   [email-masked]
LambdaMOO:  Rog

---

From: [email-masked]
Date: Wed, 15 Sep 1993 15:30:08 -0700

>   a NONPROGRAMMER WIZARD who can do everything EXCEPT create/modify verbs.

Nice idea.  I hope it gets implemented.

Norman

---

From: Colin McCormack <[email-masked]>
Date: Thu, 16 Sep 1993 09:37:40 -0700

It's, finally, the value of the .wizard pseudo-property which determines the
posession of wizard privileges, but descent from the $wizard class which
determines the facilities of which a specific wizard is capable.

It's tempting to ask whether the creation of a class of non-programmer wizards
is analogous to the creation of a class of non-programmer players (ie:
builders), and interesting to consider whether one could securely restrict
facilities from a wizard by building an analogous class of wizard-builders.

Trivially, these wizard-builders would have no access to eval, nor to chparent
themselves.

Colin (SamIAm)