couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Thu, 31 Jan 2013 16:59:40 GMT

On Jan 31, 2013, at 17:54 , Jason Smith <jhs@iriscouch.com> wrote:

> On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau <bchesneau@gmail.com>wrote:
> 
>> 
>> A javascript engine doesn't expose any IO par default. The **framework**
>> nodejs is, this is all the point. I'm quite interested by the existing
>> solutions to sandbox nodejs, do you know some projects that does it?
>> 
> 
> Correct. I am attempting to build something which satisfies your
> description: no i/o; i/o is not even possible.
> 
> *How* is it implemented? Well, it doesn't matter whether we use Node.js or
> couchjs/SM or couchjs/v8. What matters is we feel confident about security.
> And of course, I agree, if we cannot achieve good security, then that is a
> show stopper.
> 
> Here is my current plan for sandboxing CouchJS. (Thanks to Isaac for his
> tips.)
> 
> When it is time to evaluate some code:
> 
> 1. Set up an object with safe variable bindings: safe_context
> 2. fork()
> 3. Child process runs vm.runInNewContext(safe_context)
> 4. Child process communicates to the parent over stdio, through the
> approved safe_context functions
> 
> The subprocess can also give extra sandboxing, such as chroot() if
> available.
> 
> Yes, this causes two processes per instantiation; however I think the
> parent might only be short-lived, setting up the security, then exiting.
> The grandchild can talk to Erlang over stdio.
> 
> That is my plan. No idea how well it will work.

This would of course fork 2 node processes per view server launch. I think
this isn’t too bad, especially when the one is short lived, but it’d be nice
if we can avoid that. Luckily, we can then easily experiment with the query
server protocol and make this all a non-issue.

Woot!
Jan
-- 
Mime
View raw message