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 17:58:11 GMT

On Feb 4, 2013, at 18:47 , Benoit Chesneau <> wrote:

> 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
>>>> 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.

I suggested 1 extra node process in total, if at all, as an alternative,
if the thing Klaus and you outline doesn’t work.

>>> 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.

Good luck! :)

>>> 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 :)

That is because Apple doesn’t lat Google run V8 on iOS. Chrome on Android
shipped V8 in July 2012. Not exactly old and trusted, but good enough for
our future plans, I’d say :)


View raw message