Re: LuaJIT FFI __gc metamethod?
[Date Prev][
Date Next][Thread Prev][
Thread Next]
[
Date Index]
[
Thread Index]
- Subject: Re: LuaJIT FFI __gc metamethod?
- From: Josh Haberman <jhaberman@...>
- Date: Tue, 1 Mar 2011 00:39:43 +0000 (UTC)
Mike Pall <mikelu-1102 <at> mike.de> writes:
> Others have repeatedly failed to keep their sandboxes sealed. See
> Java, see Flash, see Acrobat.
Isn't every JavaScript enabled web browser in the world an example
of such a sealed sandbox? It's not to say that sandboxes never have
bugs (even process isolation can have bugs), but I don't think it's
accurate to portray in-process sandboxing as a failed experiment.
The entire web is built on it (you could theoretically run JS in a
separate process, but it would be too costly and no browser does
this AFAIK). 2B web users worldwide are constantly running untrusted
code against which their only defense is such a sandbox.
I'm surprised this is a point of contention -- from PIL 28.2:
Our current implementation has a major security hole.
Suppose the user writes something like array.set(io.stdin,
1, 0). The value in io.stdin is a userdatum with a pointer
to a stream (FILE*). Because it is a userdatum, array.set
will gladly accept it as a valid argument; the probable
result will be a memory corruption (with luck you can get an
index-out-of-range error instead). Such behavior is
unacceptable for any Lua library. No matter how you use a C
library, it should not corrupt C data or produce a core dump
from Lua.
You seem to be arguing that achieving this guarantee is not actually
feasible.
Josh