On Thu, 20 Jul 2000, Thomas Arp wrote:
> From: "Patrick Dughi"
> Subject: Re: [CIRCLE] forgot
> > Would time be better spent developing ways to access and
> > integrating external scripting languages or redesigning the mud layout so
> > as to lend itself better to a single custom, internal scripting language?
> >
> > I personally think that one custom language would be better suited
> > than making it perl/python/scheme/sml/C#/tcl/basic/java/whatever. None of
> > these have what it takes to insure mud-level security, and at the same
> > time be responsive to the most common scripting commands... the only thing
> > they really offer is the control mechanisms (while, if loops), and direct
> > access to variables, as well as aids in variable type conversion.
> > However, even for the sort of kludge it is, dgscripts already provides all
> > these admirably enough. Shouldn't we concentrate on making what we have
> > better, rather that starting over with something that isn't even made to
> > integrate with our mud in the first place?
> >
>
> I tend to agree. Since most(all?) programming languages are made with
> the idea that they should be able to tweak most variables, to be viable
> for ordinary programming purposes, they fall short for use in internal
> mud scripts due to security issues.
Looked at the "safe" and "opcode" Perl modules?
They basically restrict use of certain functions etc, so you can
potentially execute player-written code without dying a horrible death.
The other thing you can do is use tied hashes to restrict access to
certain variables (Damian Conway does a very good treatment of data hiding
in his book "Object Oriented Perl").
You can also do funky things with callers (i.e. restrict use of a function
depending on where it's being called from, by module etc), so you can put
all player executable bits in a seperate module and disallow access to
other modules based on that.
How you'd embed that sort of functionality in Circle (or similar), I'm not
sure.
I'm still designing that MUD I was writing in Perl, and this is one of the
things I was looking at to give players (or admins, at least) more
flexibility (preferably without killing the MUD).
> As someone stated in the recent discussion about the MXP protocol, a
> server/mud should not assume all scripts/users to be friendly. If a
> malicious script is written, it should be dealt with automatically - a
> solution dg_scripts solves very well. To implement ie. C as a
> scripting language would require implementation of numerous security
> measures for each possible command or a limitation of which commands
> are available to scripts - which in turn invalidates the reaons for
> using C.
If you can find a language that has that functionality built in though
. . . ;-)
Chris
+------------------------------------------------------------+
| Ensure that you have read the CircleMUD Mailing List FAQ: |
| http://qsilver.queensu.ca/~fletchra/Circle/list-faq.html |
+------------------------------------------------------------+
This archive was generated by hypermail 2b30 : 04/10/01 PDT