Subject: Re: Player security, and hiding (or the inability to)

From: Andrew Wilson <[email-masked]>
Date: Wed, 3 Feb 1993 13:03:56 -0800

Jackie ([email-masked]) says:

> We're also wanting to add the ability to hide on our MOO... i.e.
> not show up on who listings, and to anyone but a wizard it'd seem
> like you're not connected.  Problems:  connected_players(), 
> connected_seconds(), and idle_seconds() are all builtin, requiring
> yet another server hack to make it work.

Mmm, now there's a thought.  Why not have a general mechanism for making
built-ins optionally .wizard only.  Is it possible to add a compile-time
option to the server which would make certain built-ins be protected?
That way, when someone installs their server they'll be able to pick and
choose which built-ins are 'free' and which can only be accessed through
a wizarded verb.  Mmm, this doesn't make much sense does it?!

Ok, suppose that someone wants ther server to be like the standard one, but
with the connected_players(), connected_seconds() and idle_seconds() all hidden
from non wizard verbs.  When they compile their system they provide options
like:

	cc -o server server.c -DPROTECT_connected_seconds \
		-DPROTECT_connected_players\
		-DPROTECT_idle_seconds

Or whatever, you get the general idea?  Is this a sensible thing to do
Mr Curtis?  It might be useful.

A.

---

From: David Whitten <[email-masked]>
Date: Wed, 3 Feb 1993 05:23:29 -0800

Andrew Wilson was suggesting a compile time flag to specify which built-ins
should be compiled with wizard privileges.

He suggested that -DPROTECT_name_of_builtin be included on the compile line.

An alternate idea is to have a C function that is called when 'registering' 
the built-in. There could be a standard everything is the same as the released
version function defined, that links in to the other code, but we could have
a different version built as a result of running a 'server options' program
separate from the MOO-server. The program that builds the server options 
function could be run first, and then the server could be compiled using the 
function generated.

The program that builds the server option function could have the -Dblah
type options, but I don't see how adding all that to the server would be the
most reasonable.

I like this option better since there is a record of which options were chosen
in a compilable fashion, and it leans more to the you're not required to be a 
hacker to set up a MOO train of thought.

The program that builds the server options function could have a nice interface
to it, and make it easier to modify the options than remembering to put a
#define in a particular routine or so forth.
If the installer wants the plain 'normal' permissions system, all they say is
yes to the first question "do you want the standard permissions for built-ins ?"
and the program just copies the standard server options to the name that the
MOO is expecting the info to be stored in.

I think the MOO is really cool, and that pavel has done a great job, I'm just
looking toward a more 'user-friendly' install....

David ([email-masked]) US:(619)535-7764 [I don't speak as a company rep.]