lua-users home
lua-l archive

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

From: nobody <>
Date: Mon, 13 Mar 2017 12:19:19 +0100
Subject: Re: Restricted parsing for static config files / more granular `load()` options for 5.4
On 2017-03-12 20:16, Rain Gloom wrote:
> 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.
Both can be limited with debug.sethook. 

To get compute-limited sandboxing, you need pre-emption.  Your choices are either debug.sethook or modification of the Lua interpreter.

A nice examination of pre-emption is by Friedman, Wand, and Haynes ( who called such routines "engines".  The debug.sethook capability enables engines to be created in Lua.  For more fine-grained control, you could imagine modifying the Lua interpreter such that you could resume a coroutine with an extra argument specifying a limit on the computation it can do, measured in Lua vm instructions, real time, cpu time, function calls, or whatever you want.

Checking the resource usage against the given limit is the easy part.  The hard part is forcing a yield when the limit is exceeded.  This yield would likely return a first value indicating that the limit was reached (a third value beyond the true/false returned today).

The engine concept allows you to then re-resume the compute-limited routine (perhaps with a new limit).  So you can think of the "main" routine having the role of scheduler, and the compute-limited routines having the role of pre-emptable threads.

Modifying the Lua interpreter to provide engines (in addition to coroutines) would be a fun project.  Maybe someone has done this already?