[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: scope hiding suggestion
- From: "Lucas Ackerman" <ackerman@<a href="/cgi-bin/echo.cgi?wpi.edu">...</a>>
- Date: Fri, 8 Feb 2002 20:23:05 -0500
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.