couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Branch to switch from SpiderMonkey to Node.js
Date Mon, 04 Feb 2013 17:47:51 GMT
On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <> wrote:
> 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.

I don't think it is necessary at all to use so many *OS* process at
all for our purpose. And I am really worried by such solution.There is
a reason why people don't try to launch too much OS processes on the
system,  There is a reason why we are using systems like Erlang.

I guess runInContext would work, with a custom `require` function to
include modules (to specifically forbid IO) . According to the doc the
context doesn't share anything, which is what we want. Also if we are
going for node i would prefer to start with a straight forward
solution and not introduce any new behaviours.

>> 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 will work on it this week. I will probably need a second look, my
C++ is rusty.
>> 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 :)

Until recently it wasn't working on IOS, the support is really new
(chrome on IOS is using webkit). But I think now that we could let
this part to another topic. This is not like the current couchdb can
run on such platforms without deep changes :)


View raw message