--9jxplpJ6Y7QWTAUHNOq
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

On Wed, 2006-08-16 at 03:42 +0900, why the lucky stiff wrote:
> Yeah, that's just it.  I don't want to kill the whole thread
> containing the sandbox.  Just stop the eval.

Well, I was thinking of injecting a timeout exception with
rb_thread_raise() rather than unceremoniously rb_thread_kill()ing anyone
-- Sandbox#eval could catch it once it propagated up.  That should be
uncatchably secure if the exception doesn't derive from a class
accessible in the sandbox, shouldn't it?

Of course... in either the kill or exception case we still have the
problem where a malicious sandbox'd code uses a never-terminating ensure
to say "oh no you won't kill meeeee" and maybe monopolize everything.

So, I don't know.  Maybe a scheduler hack and a new jump tag is the only
way.  I just liked the watchdog idea to start with because it required
the least surgery.

> I'm shooting for:
> 
>   Sandbox.new(:timeout => 10).eval(str)

Hmm, so the timeout is cumulative for the sandbox rather than per-eval?
How do threads spawned by evals work into the accounting?

-mental

--9jxplpJ6Y7QWTAUHNOq
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQBE4i80SuZBmZzm14ERAoz/AKDG/JKzo+n4FA6QrxWENLdi5FU5OQCgpNMP
CXaGibwBtSB59+7HLoIlg44WX
-----END PGP SIGNATURE-----

--9jxplpJ6Y7QWTAUHNOq--