3 ms·

Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easi

Yes, but you use it to interface with native code. Normally, you'd write Lua_Cfunctions to achieve the same behavior - and those can crash your app just as easily, since they're native code. Perhaps more so, since it's easy to screw up the stack manipulation.

haberman 15y ago
Yes, but the point is that once you've loaded FFI you have to trust 100% of the Lua. With a Lua C extension you have to trust the extension, but not the Lua that loads it.
- justincormack 15y ago
  You can still sandbox it and not provide direct access to ffi to user code, only some tested ffi calls. Just like native in that way.
  - haberman 15y ago
    If FFI is loadable, how are you going to prevent your untrusted script from loading it and going to town? How are you going to avoid providing "direct access?" My whole point is that I don't think you can. It's all or nothing. If ffi is available to some Lua code, it is available to all of it. I even asked Mike Paul (LuaJIT author this question, and he said "That's not a viable approach for sandboxing.") http://lua-users.org/lists/lua-l/2011-02/msg01582.html http://lua-users.org/lists/lua-l/2011-02/msg01582.html
batista 15y ago
OK, native code can crash. Not much of a problem. He have been running servers written in C/C++ since the ancient times for more critical tasks than your average Lua program. From Apache to Nginx and from Qmail to MySQL to MongoDB. So what if a Lua program has the "potential" to crash if you interface with C? You do the interfacing because there is a need to do it, anyway. It's not like you go FFI for fun.
- eridius 15y ago
  haberman's argument is making an assumption that perhaps you aren't. Namely, one of the benefits of Lua is that, barring behavior introduced by C extensions (and bugs in the Lua interpreter), it can't really harm your program. It can't crash or do anything else. It can suck up resources, but that's about it. As such, with whatever sandboxing you feel is appropriate, you can run arbitrary Lua code without worrying (e.g. World of Warcraft can run third-party addons). But with LuaJIT's FFI interface, it appears (note: I have never used LuaJIT or its FFI interface) that you can no longer trust arbitrary Lua because it can reach into your program and call whatever function it feels like, including the ability to crash you at random, or do other things that it's not supposed to be able to do. You can no longer just trust Lua code to not impact the rest of your program.

haberman 15y ago

Yes, but the point is that once you've loaded FFI you have to trust 100% of the Lua. With a Lua C extension you have to trust the extension, but not the Lua that loads it.

justincormack 15y ago
You can still sandbox it and not provide direct access to ffi to user code, only some tested ffi calls. Just like native in that way.
- haberman 15y ago
  If FFI is loadable, how are you going to prevent your untrusted script from loading it and going to town? How are you going to avoid providing "direct access?" My whole point is that I don't think you can. It's all or nothing. If ffi is available to some Lua code, it is available to all of it. I even asked Mike Paul (LuaJIT author this question, and he said "That's not a viable approach for sandboxing.") http://lua-users.org/lists/lua-l/2011-02/msg01582.html http://lua-users.org/lists/lua-l/2011-02/msg01582.html

batista 15y ago

OK, native code can crash. Not much of a problem. He have been running servers written in C/C++ since the ancient times for more critical tasks than your average Lua program. From Apache to Nginx and from Qmail to MySQL to MongoDB. So what if a Lua program has the "potential" to crash if you interface with C? You do the interfacing because there is a need to do it, anyway. It's not like you go FFI for fun.

eridius 15y ago
haberman's argument is making an assumption that perhaps you aren't. Namely, one of the benefits of Lua is that, barring behavior introduced by C extensions (and bugs in the Lua interpreter), it can't really harm your program. It can't crash or do anything else. It can suck up resources, but that's about it. As such, with whatever sandboxing you feel is appropriate, you can run arbitrary Lua code without worrying (e.g. World of Warcraft can run third-party addons). But with LuaJIT's FFI interface, it appears (note: I have never used LuaJIT or its FFI interface) that you can no longer trust arbitrary Lua because it can reach into your program and call whatever function it feels like, including the ability to crash you at random, or do other things that it's not supposed to be able to do. You can no longer just trust Lua code to not impact the rest of your program.