couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Mon, 04 Feb 2013 11:10:34 GMT

On Feb 4, 2013, at 11:53 , Benoit Chesneau <> wrote:

> On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith <> wrote:
>> On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau <>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.
>> --
>> Iris Couch
> Too much kool-aid imo :)
> This is not that it can't work. But are you seriously considering to
> have a main couchjs process maintaining the STDIO channel and spawn a
> new OS Process for a view (which what does  `vm.runInNewContext`)? The
> memory and latency cost can became very important, and i don't count
> the chrooting cost especially if run this context on each indexation
> batch or shows, lists and views requests. + the extra fds created by
> each child contexts.

Alternatively, if the above works and is necessary (modulo Klaus’s
research), we live with the hit until we get to rewrite the view protocol
at which point we can make it 1 Erlang process -> 1 node process for 
dispatching -> N Node processes for indexing.

> Anyway, I looked over the week-end and didn't find so may other
> solutions when it's about nodejs. I read that and maybe `
> vm.runInContext` [1] with `vm.CreateContext` could work or like Klaus
> says maybe `vm.CreateScript` though the doc[1] don't say if it s in
> the same process or not [2]. I guess it is. I'm interested by the
> solution of providing a secure "require" like suggest Klaus. How would
> it work?

Yeah, I’d love to see that too.

> I intend to write a straight-forward port of couchjs to use v8 to see
> how much things it gave us, but it will be just a temporary hac, just
> good for 1.4 imo.

It’d be great to have this as a fallback solution! If we eventually can
do away with all the C code, the better :)

> I also would like to find a solution for the mobile
> worl and i'm not sure v8 is OK for that yet.

It works fine for Chrome on mobile :)

> Just some thoughts, it's cool to see such activity on this topic :)

+1000, keep em coming :D


View raw message