Re: Lua hits OSDI 2010

[Patrick Donnelly <batrick@...>]

On Wed, Oct 6, 2010 at 3:15 PM, David Kolf <kolf@gmx.de> wrote:
> Patrick Donnelly wrote:
>> They apparently don't know Lua threads are coroutines and are
>> basically harmless for their sandbox needs. :( It sounds like they use
>> hooks for bytecode count limits and a custom allocator for memory
>> limits.
>
> If you enforce CPU limits by setting debug hooks, coroutines are a problem:
>
> function test ()
>  for i = 1,400 do local a = 0 end
> end
>
> debug.sethook (function () print "h" end, "", 100)
>
> print ("Same coroutine:")
> test()
>
> print ("Another coroutine:")
> co = coroutine.create (test)
> coroutine.resume (co)
>
>
> You could solve it by providing an own coroutine.create function that
> copies the hook and the remaining count.

The hook actually is copied but the base library identifies the *Lua
hook function* based on the thread running. Your example would work if
you were using C hook functions.

In any case, debug hooks *are* a poor mechanism for enforcing run time
except in the smallest sandboxes. Even when you add the string library
into the mix, they are basically worthless.

The main problems facing sandboxes using hooks that include most of
the Lua base libraries is:

  (a) Getting the base library functions to stop if they are long
running (e.g. string.find). I have suggested a solution for this in
[1].
  (b) Preventing users from using up all the memory via nested concat
operations. This would be fixed if users could set a limit for memory
usage in Lua (it's easy to do through the C API).
  (c) Prevent users from loading malicious bytecode (as previously mentioned).

I don't want to hijack this thread anymore, so that's all I will say
about it here.

[1] http://lua-users.org/lists/lua-l/2009-04/msg00413.html

-- 
- Patrick Donnelly