Re: LuaJIT FFI __gc metamethod?

[Josh Haberman <jhaberman@...>]

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