4 ms·

It is very hard to sandbox lua properly. Embedded scripting sounds good, but in most cases is more of a liability.

• antirez 11y ago
  When you let a program run other, externally provided programs, there are always risks. I agree. But in the case of Redis Lua scripting, the risks were definitely counter balanced by what the community did with this feature in the latest years. Today is hard to imagine Redis without Lua scripting capabilities.
  • catwell 11y ago
    It is much easier to sandbox Lua than most other scripting languages. If you have a very adversarial security model, do not offer your users any chance to run in-process Turing-complete scripts. But if you do want that feature, Lua is the best language I can think of (at least that is not a LISP). Lua bytecode has been known to be vulnerable for a long time, which is why there is no more bytecode sanitizer in the language. If you load untrusted code from Lua, always use mode "t". This is documented in Lua 5.3: http://www.lua.org/manual/5.3/manual.html#pdf-load http://www.lua.org/manual/5.3/manual.html#pdf-load If you want to implement a Lua sandbox, start with this post by Lua author: http://lua-users.org/lists/lua-l/2013-12/msg00406.html http://lua-users.org/lists/lua-l/2013-12/msg00406.html and this repository by a prominent member of the Lua community: https://github.com/kikito/sandbox.lua https://github.com/kikito/sandbox.lua
• benmmurphy 11y ago
  for most use cases it doesn't matter because you trust everyone who can connect to the redis server. however, it was possible to CSRF against dev's boxes and some people offer cloud redis and might not properly isolate the redis instances. probably most DBs that offer scripting languages are vulnerable to RCE.
• vasquque 11y ago
  If you wish to use lua more well use http://tarantool.org http://tarantool.org than redis.