scope hiding suggestion

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

I like the things I hear about the near term Lua changes (lexical 
scoping, block comments, unified method tables, etc), but with the 
removal of upvalues a curious little feature dissappears which could 
perhaps be compensated for.

Since an upvalue originally only accessed the immediately enclosing 
scope (iirc, it's now a synonym for lexical scope behavior), one 
could "hide" scope from unsafe code by wrapping it with a function 
that provided no upvalues.  The application is naturally any sort of 
program which benefits from executing code which may be 
insecure, for example, because it's from a user input or was 
recieved on a network.

So, what's needed to regain this execution safety is a method to 
hide enclosing scope.  One might store all potentially dangerous 
globals in a local table, replace the global table with only the minimal 
necessary safe functions & data, and then call a system function, 
say ExecuteSandbox(safe_globals, untrusted_func, params).  If also 
providing a new set of locals is necessary for context, that may work 
too (though this is certainly doable by wrapping the untrusted_func). 
 It may be useful to have ExecuteSandbox() store the normal global 
table temporarily by default.  The specific semantics can be worked 
on, but simpler is probably better.

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.

I would impliment this myself and release a patch, but I'm not 
anywhere near familiar enough with the Lua source.  I suspect it 
may be a relatively simple thing to do.  The ExecuteSandbox() fn 
maybe needs an opcode that removes enclosing lexical scope for 
it's duration.  It would be a nice capability for Lua to retain.

-Lucas