[DGD]Default Wiztool not loaded ?

[Stephen Schmidt]

On Sun, 18 Feb 2001, Felix A. Croes wrote:
> That would concentrate security-related code in fewer objects, but it
> would still require different privileges for commands performed by
> the same object, depending on what player is executing the command.
> I consider this a possible weakness, and it has been an actual
> weakness for many mudlibs in the past.

Agreed - but doesn't the wiztool have a similar weakness?
For instance, consider the set_global_access() function
in /kernel/lib/wiztool.c. That function requires different
privileges depending on who invokes it. The main difference
that I see is that each different wizard will have a 
different clone of the wiztool (perhaps each wizard
having a different file inheriting the kernal wiztool,
perhaps extending it, perhaps not), but with the command
bin, all players use the master copy. But why does that
make a difference? The set_global_access() function does
not check any of the internal data of the object, except
for the owner; but how is checking the owner of each individual
clone so different than checking the identity of the user that
invoked a command, assuming one uses previous_program()
to secure each command against being invoked by anything
other than a user? Surely it is just as easy to fake
the one as to fake the other?

Not criticizing, or suggesting the other method is better;
just seeking to understand why Dworkin considers the wiztool
method advantageous.

(Side note: Melville appears not to check whether the
object invoking a call is a user object; it only checks
whether the user has "admin" privileges. However, "admin"
privileges can only be assigned to a user object, so
in fact Melville is restricting access to user objects,
and indeed, only a subset of those.)

Steve








List config page:  http://list.imaginary.com/mailman/listinfo/dgd