lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]



> On Behalf Of Rici Lake
>A lexical analyzer will not tell you which Lua functions a program is 
using. However, you can arrange for only the functions you truly trust 
to be available in the Lua runtime. If the function is not loaded into 
the Lua runtime (or if it is deleted) then it is no longer available. 
Period.
> It is perhaps slightly surprising that sandboxing Lua is quite simple,

compared with other scripting languages. I hope that this feature will 
continue to receive high priority as the Lua packaging system develops.

Sandboxing is indeed very easy. The idea is that you prevent rather than
cure. I've got a sandboxed version of Lua running here:

http://doris.sourceforge.net/lua/weblua.php

Alain, I do agree with you somewhat, that it would be nice to be able to
detect more of what a user is doing at compile time. I'm thinking more
in terms of misspelled objects etc calls rather than security issues,
which aren't impossible to detect, but current require parsing of the VM
code (and not all instances are easy to detect, as per the previous
examples).

This is a common complaint for people scripting in Lua (well in dynamic
languages, not just Lua) that easy mistakes aren't picked up until
runtime, whereas a statically compiled language would have picked this
up in the compile or link phase. This isn't such a problem if you have a
little script that executes and exits in 2 seconds, but if you have a
larger script that drives something and takes 5 minutes to hit a
spelling mistake, it can be irritating.

Work on "Lua macros" might fix both these issues. In your case you could
look for calls and box them, and my case I could check global object
lookups, where possible. It would also be possible to restrict the
syntax, where perhaps "extra syntax" is not necessary. 

So another option would be to look at the LHFs ltokens library:

	http://www.tecgraf.puc-rio.br/~lhf/ftp/lua/

Nick