[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Restricted parsing for static config files / more granular `load()` options for 5.4
- From: Rain Gloom <raingloom42@...>
- Date: Sun, 12 Mar 2017 19:16:52 +0000
TLDR: just like we can disable bytecode loading, we should be able to disable certain language constructs, creating fully sandboxed configs
The biggest problem that simple _ENV sandboxing can't avoid is infinitely long running code, one would need either the debug library to block a script after N instructions or use their own parser.
In more detail, what can pose the biggest problems are loops and recursions. The latter can be hacked around with `debug.sethook` but loops require either bytecode inspection, a custom parser or a simple token based checking algorithm.
Bytecodes are not portable and a full parser is unnecessarily big if the author just wants to block a few language constructs.
I am not sure how well a token parser would work, it is still too complicated imo, even if it does not mean two parsers running at once doing the same thing, it is still a pointless duplication of effort.
My solution would to add more option to the `load()` functions that could manipulate what the parser should accept. The recursion problem is a bit more difficult, based on my understanding of Lua, it would either have to hook in at the compiler level, but that is only feasible when recurring on locally defined functions, as expecting the compiler to figure out if passing the local function to another would mean that the other function would somehow call that first function and end up in some weird recursion would be too much work (complex graph analysis would have to be involved to make it correct).
So recursion is really best solved with `debug.sethook` and inspecting each call event to determine if the function is already on the stack.
So, what are everyone's thoughts? Is this actually a problem in the wild?