Open crionuke opened 11 months ago
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.
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) orload
(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?
@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:
load
(Lua 5.2 and on) or setfenv
(Lua 5.1) on the Lua side,Or use the Lua C API bindings:
(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.).
@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)?
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
@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 LuaJava
v4.0.0
has been released and methods inLuaNatives
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 usingLua::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!
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?