lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Mike Pall <mikelu-1102 <at> mike.de> writes:
> Josh Haberman wrote:
> > What you are saying applies only to FFI, right?  Without FFI,
> > can't either Lua or LuaJIT be very tightly sandboxed in-process
> > with an approach like this?
> >   http://lua-users.org/wiki/SandBoxes
> 
> No, it applies to Lua in general. The advice in that page is
> incomplete and outright dangerous. E.g. string.find() can lock up
> your CPU and, nope, setting a hook won't help here:
> 
> string.find(string.rep("a", 50), string.rep("a?", 50)..string.rep("a", 50))

While a CPU DoS is bad, it doesn't seem to be the same as actually
breaking out of a sandbox.  For example, suppose you had a design
where the entire process acts on behalf of a user but has access to
sensitive resources that the user should not have access to (for
example, an AppEngine-like case).  You could run the user's code
sandboxed, but if it exceeds a set amount of CPU time it is killed
by a separate process.  The user has still been effectively sandboxed
from accessing sensitive resources like the local filesystem.

You might even be able to do a thing like this in-process with
pthread_cancel() (it has cleanup handlers that are run in the
cancellation case), but I have no experience with this so can't say
whether this would work or not.

Josh