3 ms·

I'd be surprised if it could prevent a script from running indefinitely. In particular, limiting the number of Lua bytecode instructions is insufficient FTA: “

I'd be surprised if it could prevent a script from running indefinitely. In particular, limiting the number of Lua bytecode instructions is insufficient FTA: “Lua has a facility to interrupt a script after it has run a certain number of instructions.”

OskarS 6y ago
string.find is implemented in C, not Lua. As far as Lua is concerned, that call is a single instruction.
- DarkWiiPlayer 6y ago
  A single instruction that can run for a long time. That's the point.
  - pctammela 6y ago
    ditto for eBPF when acessing the C helpers
- dathinab 6y ago
  You could have a string.find C implementation which gets an additional budget parameter and depending on it might limit search or similar (and reports back how much "budged" was used) Through always under the assumption that the C function is implemented correctly and adding need to do some explicit budged keeping makes it more complex and in turn more prone to errors.
raverbashing 6y ago
Just add a time limit to the sandbox as well
- lioeters 6y ago
  Apparently, the sandbox cannot enforce such a time limit. From a similar thread to the one linked from the root comment: > ..Attempts to control untrusted scripts may be in vain. E.g. string.find, string.rep and other C functions can be abused and will either run forever or allocate unlimited amounts of memory. This is true for both Lua and LuaJIT. > The only reasonably safe way to handle untrusted Lua scripts is to isolate them in a process context and to make use of per-process quotas/limits provided by the operating system. Improved functions sandboxing in Lua and LuaJIT - http://lua-users.org/lists/lua-l/2011-02/msg01106.html http://lua-users.org/lists/lua-l/2011-02/msg01106.html
- smilliken 6y ago
  This solution is problematic because there's no one time limit that makes sense across all past and present CPUs that span orders of magnitude of performance.. your lua script would always fail on some CPU and there wouldn't be a way to fix it.

OskarS 6y ago

string.find is implemented in C, not Lua. As far as Lua is concerned, that call is a single instruction.

DarkWiiPlayer 6y ago
A single instruction that can run for a long time. That's the point.
- pctammela 6y ago
  ditto for eBPF when acessing the C helpers
dathinab 6y ago
You could have a string.find C implementation which gets an additional budget parameter and depending on it might limit search or similar (and reports back how much "budged" was used) Through always under the assumption that the C function is implemented correctly and adding need to do some explicit budged keeping makes it more complex and in turn more prone to errors.

raverbashing 6y ago

Just add a time limit to the sandbox as well

lioeters 6y ago
Apparently, the sandbox cannot enforce such a time limit. From a similar thread to the one linked from the root comment: > ..Attempts to control untrusted scripts may be in vain. E.g. string.find, string.rep and other C functions can be abused and will either run forever or allocate unlimited amounts of memory. This is true for both Lua and LuaJIT. > The only reasonably safe way to handle untrusted Lua scripts is to isolate them in a process context and to make use of per-process quotas/limits provided by the operating system. Improved functions sandboxing in Lua and LuaJIT - http://lua-users.org/lists/lua-l/2011-02/msg01106.html http://lua-users.org/lists/lua-l/2011-02/msg01106.html
smilliken 6y ago
This solution is problematic because there's no one time limit that makes sense across all past and present CPUs that span orders of magnitude of performance.. your lua script would always fail on some CPU and there wouldn't be a way to fix it.