Re: On implementing a functions whitelist for a sandbox

[Sean Conner <sean@...>]

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
> [stackoverflow](https://stackoverflow.com/questions/57325179/).

  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 [1]).

> Considering all the available information it seems that:
> 
> - Whenever an error happens in Lua, some unknown function X is called
> internally

  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

  Yup.

> 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.

  Sandboxing?

> Trying to call `error 'foobar'` with the hook set the error changes only
> slightly:
> 
> "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
upvalues.

> - 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

  Yup.

  -spc

[1]	There are other ways to limit the CPU time, but they tend to be
	system dependent.