Re: scope hiding suggestion

["Lucas Ackerman" <ackerman@...>]

> >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.

I'm sure many people have thought of it, but you're the first I've 
heard to be applying this.  It does seem fairly obvious given Lua's 
flexibility and power.  Congrats, and good luck with it.
 
> 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

Ok, so that is already doable, but it's not what I'm asking for.  In 4.0, 
you can get away with just hiding globals, and in your case you 
don't need to do this from within Lua.  But if someone does want to 
do this within Lua (I can think of any number of reasons - 
demarshalling object references, more flexible sandbox setup, etc), 
with a more recent build that uses lexical scoping, then they need to 
be able to hide the enclosing scope, which was the real point of this 
suggestion.

There are probably other applications too, the distributed game code 
one is just convienient, and not everyone is going to want to relegate 
this non-trivial behavior to some other hardcoded layer.  

Lexical scope has its place, but in this case, to secure a sandbox 
purely within Lua, you also need to hide the local scope that the 
permenant globals have been hidden in.  There may well be non-
sandbox applications for this, where it's just a simpler and cleaner 
solution to execute something with a clean (empty) scope.

In cases where lexical scoping is useful, it is probably a much 
simpler solution to use than whatever the alternative is, but having it 
available doesn't mean there can't be places where you don't want it.

-Lucas