[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: scope hiding suggestion
- From: "Lucas Ackerman" <ackerman@<a href="/cgi-bin/echo.cgi?wpi.edu">...</a>>
- Date: Mon, 11 Feb 2002 14:55:15 -0500
> >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;
> 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
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
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.