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 Tue, 05 Feb 2013 10:33:53 GMT

On Feb 5, 2013, at 08:26 , Benoit Chesneau <bchesneau@gmail.com> wrote:

> On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt <jan@apache.org> wrote:
>> 
>> On Feb 4, 2013, at 18:47 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>> 
>>> On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <jan@apache.org> wrote:
>>>> 
>>>> On Feb 4, 2013, at 11:53 , Benoit Chesneau <bchesneau@gmail.com> wrote:
>>>> 
>>>>> On Thu, Jan 31, 2013 at 5:54 PM, 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.
>>>>>> 
>>>>>> --
>>>>>> 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.
>> 
> Why doesn't it work?

I was speaking hypothetical. We’ll have to wait for the code & tests to
see how it turns out. I am optimistic, I just wanted to leave open the
possibility of us finding some blocker.

Best
Jan
-- 


> 
> runInNewContext would imply to launch one new context / view if you
> want to really run it sandboxed.
> 
> "vm.runInNewContext compiles code, then runs it in sandbox and returns
> the result.".
> 
> I don't see any other way since you can't recycle a context in this
> case. Having another I/O for this context wil be even uglier. In that
> case you would have STDIO -> CHILD -> STDIO -> CHILD . Without
> counting the memory usage it will add more latency than we have right
> now. The more I think about that the more I'm reluctant to support
> such solution.
> 
> - benoît


Mime
View raw message