[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: On implementing a functions whitelist for a sandbox
- From: Sean Conner <sean@...>
- Date: Thu, 8 Aug 2019 12:01:52 -0400
It was thus said that the Great Dennis Fischer once stated:
> Greetings mailing list,
> first of all, I'd like to point out that this has already been discussed
> (with limited success) on
Ah, now that I see what code was presented in _Programming in Lua_ for
sandboxing, I can see where the confusion comes froms. The approach in the
book is *not* one I would take for sandboxing---not only is it slow, but it
can have weird results (although I see it was also attempting to limit the
amount of CPU time the sandboxed code would run, so perhaps that's why that
particular approach was taken ).
> Considering all the available information it seems that:
> - Whenever an error happens in Lua, some unknown function X is called
I was able to track down said function, msghandler() (from lua.c)
but it's not one that is listed as a public API.
> - This function X does not appear on the function whitelist, thus causing
> another error
> - The new error shadows the previous error message, making sandboxed
> code near impossible to debug
> As OP pointed out in another reply, the purpose of this exercise seems to
> be getting a better understanding of the Lua language, not to satisfy any
> real world use-case.
> I personally also find this problem very interesting.
> Trying to call `error 'foobar'` with the hook set the error changes only
> "calling bad function ([C]:-1): ?"
> Some logical conclusions:
> - `error` seems to be written in C; as such we won't be able to just
> peek into its upvalues
Actually, you can with debug.getupvalue() but error() doesn't have any
> - X is most likely not a plain C function, but a C closure within the
> Lua state, since the hook is called
> - X has no meaningful name here because it's called from a C function
 There are other ways to limit the CPU time, but they tend to be