Cameron Laird a ?crit :
> In article <ekel45$351$1 / upsn250.cri.u-psud.fr>,
> Laurent Pointal  <laurent.pointal / limsi.fr> wrote:
>> Fred Bayer a ?crit :
>>> Tony Belding wrote:
>>>> I'm interested in using an off-the-shelf interpreted language as a
>>>> user-accessible scripting language for a MUCK.  I'm just not sure if I
> 			.
> 			.
> 			.
>>>> there's the security issue that really worries me. . .  I have to be
>>>> able to limit what the interpreter can execute.  I can't have my users
>>>> running scripts that access the console, access the filesystem or
>>>> sockets directly, or call libraries or other binaries outside the MUCK.
>>>>
>>>> Is this practical?  I'm thinking of Ruby or Python for this, if they
>>>> can meet the requirements.
>>>>
>>> Don't forget Lua: www.lua.org
>>> It fulfills your requirements and is easily embedable.
>>>
>> I Agree with F.Bayer, when reading OP post, I immediatly think about Lua.
> 
> Does Lua have an appropriate security model--a sandbox or such?
> Fond though I am of Lua, such would be news to me.

I dont think of a security model like in Java, but in the possibility to
limit the accessible libraries for interpreted code.

	http://www.lua.org/manual/5.1/manual.html#5

If OP just need some computation logic, he could limit external world
communication libraries (these libraries must be loaded by the C host
program before being usable by scripts).
Need to look more precisely to the minimum library set to load and to
available functions in this set. Maybe it is possible to remove some
undesired functions from Lua symbol tables just after loading libraries.


[note: I have still not used Lua, but I look at it for futur use in a
current development where an embedded Python would be too heavy and make
problems relative to the GIL - but I'm still a Python fan in other use
cases]

A+

Laurent.