[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: sandboxing turns into pain in the ...
- From: Tomas <tomas@...>
- Date: Tue, 7 Mar 2006 11:44:21 -0300 (BRT)
Lets consider sandboxing require, here is problems we will encounter:
We faced that problem some time ago while redesigning CGILua.
Then we started VEnv, which solved some problems (and added others :-)
0. We can't do setfenv(require, sandbox), because it'll break global
require. So we need a way to clone functions.
There is a way to dump a function but you lost the upvalues.
1. require uses registry to store loaded packages, so setfenv(require,
sandbox) won't protect our package.loaded
2. We need to sandbox loaders (as well as already loaded packages). Here
problems we will encounter:
2.1. CFunctions' globals are globals, LuaFunction's globals are environment
variables. (Have you ever heard about this malicious difference?
OP_GETGLOBAL?! Ha-Ha.). So we need to use different approaches.
For that reason we gave up with VEnv and started another way:
Rings is the name of the library which creates new Lua States from within
Lua. We're using it successfully on some production applications from some
2.2. Callee does not inherit environment of caller. (Ah, you've already
sandboxed only caller? Now go and sandbox its children)
I think this is another point.
We're almost releasing the first official release of Rings.
Wait just a couple of days :-)