lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


On Fri, 8 Feb 2002 20:23:05 -0500, "Lucas Ackerman" <ackerman@wpi.edu>
wrote:

>Here's a (hypothetical) example.  In my distributed multiplayer game 
>scenario, game code is sent to players at runtime for a variety of 
>reasons (security, updates, flexibility, generative content, etc).  The 
>game code itself gets plugged into their Lua environment by the 
>system, but when it runs the game code should clearly not have 
>access to system internals, only to the game objects themselves.  
>That is, the system does game object class setup stuff (so settag 
>can't be malicious, as possibly pointed out by the "Proposal for 
>Protected Types" thread on lua-l), and then explicitly hides the 
>dangerous system functions before running the game code, so that 
>it can't possibly change objects types, do system damage, etc, and 
>has access only to a select few system functions, such as those for 
>creating new game objects.

We're doing that for game code as well, in a slightly more
sophisticated (and much less hypothetical!) way.  You can provide any
number of different sandboxed runtime environments by swapping the
global table in and out.

This is in Lua 4.0:

	*ourLuaState->top = table;
	ourLuaState->top++;
	lua_setglobals(ourLuaState);

Where "table" is a TObject of a table, which you've either retrieved
or made elsewhere, and only has the functions and data you would like
the sandboxed code to access.

I don't think this needs to be a function inside Lua, it is the sort
of thing that you can do if you like in your layer round Lua. It's
very specialist depending on the application.

Added bonus: If a chunk of code (um, why don't I just say agent?)
writes to its global table, it won't destroy key functions for other
agents.

Francis