Outstanding Features of 2.0

[gf3]

There are two main outstanding features preventing the release of sandbox 2.0:

• Capturing output - Capturing output is a simple way of communicating out of the sandbox securely.
• Timeouts - Timeouts are an important feature to prevent indefinite execution. They're also more complicated to implement properly.

Capturing Output

It likely makes the most sense to replicate the console API from within the sandbox (i.e console.log, console.error, etc...). These APIs are simple and they don't need to support outputting structured data—just strings. However, I'm undecided on the best way to expose this data outside of the sandbox. The most idiomatic API is probably a stream that emits data when the console API is called inside the sandbox. There could either be separate streams for both stdout and stderr or perhaps the sandbox instance could be a readable stream itself, passing along all data. Either way, the APIs are fairly similar and relatively straightforward to implement.

Timeouts

In the previous version of sandbox we relied on string-based IPC for execution and communication. This was not very robust but it made it much easier for the parent to manage the child, particularly if a child ran for too long. The current version of sandbox uses a more sophisticated threading model which should have a lower overhead and allow us to communicate complex values. That being said, fine-grained thread management in Rust is tricky and perhaps impossible to do in a platform agnostic way. By default, Rust does not expose the data and APIs necessary to effectively manage a thread externally—an implementation I'm currently toying with loads platform-specific extensions to make unsafe calls to libc's pthread_kill, pthread_exit, and thread-local signal handling via SIGUSR1. While this appears to work it is currently not very safe and I'm not sure it could be made fully safe. Additionally this model would need to be translated to something else for Windows (or any other OS that doesn't support libc). There is an alternative which is to do timeout management on the JavaScript side of things, but there are still many unknowns there too. And we'd still need a way to clean up after ourselves so we don't leave orphaned threads running at 100% CPU (e.g. while(true){}).

This feature is going to take a little more thought and experimentation. Ideas, thoughts, and suggestions welcome!