lua-users home
lua-l archive

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


> It doesn't seem to handle a simple case like:
>         while 1 do end

> > I haven't done this yet, but a standalone parser could be written in C...
> 
> Yes, that makes sense - even if you _are_ working in Lua a restricted
> parser is useful. I understand that the JS community frowns on those
> lazy nutcases who just eval JSON ;)

Lightroom uses Lua as a data description language with sandboxing.

It has crossed my mind on a few occasions to use the disassembly routine
we use for some of our linting to provide another level of protection
against malicious chunks by disallowing binary chunks and rejecting any
source chunks whose compiled forms involve any of the looping and function
call related instructions.

Given a chunk with an empty environment (no functions to call), the creation
and population of plain tables would get a similar safety level to a restricted 
parser and would make it guaranteed to be compatible with the "real" one.

If you have a few functions exposed in the provided environment, you could 
allow call but still disallow loops and the closure instruction (creation of new 
functions), so there might be a few levels of restriction to consider.

The newly added mode parameter on the load function in 5.2:
  http://www.lua.org/manual/5.2/manual.html#pdf-load

could easily be augmented to support an "r" (for restricted) option to apply 
an opcode filter suitable for JSON-like use of Lua.

It seems a fairly natural place to put such a feature.

Dan Tull
Lua Tools Dev
Adobe