rvirding / luerl

Lua in Erlang
Apache License 2.0
1.02k stars 140 forks source link

Sandboxing is unclear (specifically referring to the standard library) #162

Closed ethindp closed 5 months ago

ethindp commented 9 months ago

I can't seem to find an example of this, but what's the proper way of preventing Luerl from opening the standard libraries? (I want to implement my own, and I don't want my code having access to it, hence my question.) I could just overwrite the tables, I suppose, but that doesn't seem like the best solution.

rvirding commented 9 months ago

That is the easiest solution.

As Luerl is defined today and with the existing libraries from inside Lua there is no way to load modules written in erlang/elixir into the system., you can only load code written in Lua. You can only load modules which interface and access Erlang code from the surrounding erlang/elixir environment. This is the basis for the sandboxing. So it goes through all tables and overwrites the "dangerous" functions to the string "sandboxed". Calling them will then just generate an error. A slightly better way might be to reference an existing function in a table which generates a slightly more informative error.

If you add your own tables which access potentially dangerous Erlang code then you would have to do the same thing when sandboxing.

This works because Luerl has its own Lua VM which handles this.