Hacker News Reader

Consensus in the community is that Lua(JIT) sandboxing must be done on the process level.

Even with the debug library stripped and other safeguards against (inner) evaluation taken, the trivial DOS of `while true do end` remains.

If that happens, you want it to live in its own process, or at least its own thread.

View on HN

Those kind of dos (while true do end), actually we handle quite well already, because we don't use LuaJIT but plain Lua that has hooks that allow Redis to detect such conditions. But in general, it's a "can of worms" indeed.

iirc and ime, that sort of provision in Lua only allows you keep running at a cost. You'll still encounter hitching because infinite loop detection is based on a detection of number of line executions.

Yes, but in the case of Redis the fact that an user makes its own Redis server slower is not an issue basically. It is enough that we can detect this and kill the script.

Are your Lua changes public? I couldn't find a relevant repo. Thanks.

If you have the time he has a great video here[0] that talks about redis+LUA

[0] https://www.youtube.com/watch?v=RaIwBagADVM

Yes but there is no direct modification to the Lua code, we just install the hooks from the Redis source code using the Lua interpreter. So the implementation of that is directly inside the Redis source tree, scripting.c file.

Reply on news.ycombinator.com