On 8/22/05, Alain <alainm@pobox.com> wrote:
Thanks Ben for the information, but that is not enough. It does protect
a function to alter some things, but a skilled (auto-nominated) can use
other ways to access what he is not suposed to use.
I what I really am looking for is validating a minimal Lua-subset and
avoiding commands unknown by me to get into the scripts.
I am Ssorry to ask the same quastion 3 times, but I feel that I did not
make myself clear enough :(
I don't think you quite understand. In Lua, the only way to access or
change things outside the "sandbox" is through functions. If you don't
expose any functions that give users the power to change stuff, they
won't be able to change stuff no matter how "auto-nominated" (?) they
are. There is simply no way for a script to add functions which do
things the script couldn't already do.
Here's an example: WebLua, available at
http://doris.sourceforge.net/lua/weblua.php . This script executes
arbitrary code server-side, and as far as I know doesn't need anything
for full security except a carefully chosen set of global functions
and normal limits on CPU time and memory usage.
You'll find that when it comes to sandboxing, simple solutions are
usually more secure than complicated ones. Trying to perform static
analysis of a script's security is more or less impossible.
