Sandboxing for this project

[crionuke]

Hello! First of all, that's a great project and docs, thanks! And I have a question regarding sandboxing. Do you have any instructions/examples about running of untested Lua code with this lib?

[gudzpoz]

I recommend reading http://lua-users.org/wiki/SandBoxes .

A basic idea is to provide a "safe" [^1] environment table for the code to execute in (either with setfenv (Lua 5.1) or load (Lua 5.2 or later)).

[^1]: In addition to the globals described in http://lua-users.org/wiki/SandBoxes, LuaJava provides a java package, which I consider unsafe.

[Curve]

I recommend reading http://lua-users.org/wiki/SandBoxes .

A basic idea is to provide a "safe" 1 environment table for the code to execute in (either with setfenv (Lua 5.1) or load (Lua 5.2 or later)).

Footnotes

1. In addition to the globals described in http://lua-users.org/wiki/SandBoxes, LuaJava provides a `java` package, which I consider unsafe. [↩](#user-content-fnref-1-b71fde8e003dfbcdee056621e75125fa)

Hi, I'm currently testing out this library and was wondering how I could call lua__setupvalue to set the env properly?

[gudzpoz]

@Curve Lua 5.2 and newer Lua versions are not compatible with Lua 5.1 regarding upvalue API and we do not provide a public API to do this across versions. Depending on the version of Lua you use, you may either:

1. Use load (Lua 5.2 and on) or setfenv (Lua 5.1) on the Lua side,

2. Or use the Lua C API bindings:

   • lua_setfenv on Lua 5.1
   • lua_setupvalue on newer Lua versions

   (They are protected so you will need to extend the class to gain access to them. Also make sure to familiarize yourself with Lua C API.)

   Update after v4.0.0: These methods are now made public. However, they are not present in the LuaNatives interface, since lua_setfenv is removed in Lua 5.2 and lua_setupvalue is not supported in Lua 5.1. For anyone trying to use these methods, you will need to cast your LuaNatives instance (from Lua::getLuaNatives) to the corresponding implementation class (Lua51Natives, Lua53Natives, etc.).

[Curve]

@gudzpoz Thanks for the fast reply!

I'm familiar with the Lua C-API and already got it working by using reflection, I was just wondering because the natives are not exposed to the end-user which seemed a little odd to me - maybe the lua c-functions should be public in the natives class (i.e. make them public in a LuaNatives54 class)?

[dayo05]

IMO because almost of method inside the Lua class are just wrapper for native and it doesn't makes lots of difference between direct call to Lua-C function or calling via interface Also because its just wrapper, if there are missing function, its easy to implement it

[gudzpoz]

@Curve LuaJava v4.0.0 has been released and methods in LuaNatives are now made public (along with other breaking changes). I was originally considering these raw bindings dangerous and should require something more than a type cast to use. But since using Lua::getRaw on a non-table value will, too, efficiently crash the JVM, maybe making the bindings public is probably OK.

[Curve]

@Curve LuaJava v4.0.0 has been released and methods in LuaNatives are now made public (along with other breaking changes). I was originally considering these raw bindings dangerous and should require something more than a type cast to use. But since using Lua::getRaw on a non-table value will, too, efficiently crash the JVM, maybe making the bindings public is probably OK.

Nice to hear, thanks a lot!