Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 46DD0EDF9 for ; Mon, 4 Feb 2013 17:58:41 +0000 (UTC) Received: (qmail 37872 invoked by uid 500); 4 Feb 2013 17:58:40 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 37782 invoked by uid 500); 4 Feb 2013 17:58:40 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 37774 invoked by uid 99); 4 Feb 2013 17:58:40 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2013 17:58:40 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: local policy) Received: from [80.244.253.218] (HELO mail.traeumt.net) (80.244.253.218) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2013 17:58:32 +0000 Received: from [10.0.0.13] (91-66-82-235-dynip.superkabel.de [91.66.82.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mail.traeumt.net (Postfix) with ESMTPSA id 4278814050 for ; Mon, 4 Feb 2013 18:53:52 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) Subject: Re: Branch to switch from SpiderMonkey to Node.js From: Jan Lehnardt In-Reply-To: Date: Mon, 4 Feb 2013 18:58:11 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0377F01C-5F5D-48C5-8FDA-F9269B480324@apache.org> References: <5102B439.10500@lymegreen.co.uk> <91019D9B-A6AE-4311-9C11-E6001D57293A@apache.org> <5DD875C7-7E61-4FB8-A79C-779363AE5659@apache.org> To: dev@couchdb.apache.org X-Mailer: Apple Mail (2.1499) X-Virus-Checked: Checked by ClamAV on apache.org On Feb 4, 2013, at 18:47 , Benoit Chesneau wrote: > On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt wrote: >>=20 >> On Feb 4, 2013, at 11:53 , Benoit Chesneau = wrote: >>=20 >>> On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith = wrote: >>>>=20 >>>> On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau = wrote: >>>>=20 >>>>>=20 >>>>> 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? >>>>>=20 >>>>=20 >>>> Correct. I am attempting to build something which satisfies your >>>> description: no i/o; i/o is not even possible. >>>>=20 >>>> *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. >>>>=20 >>>> Here is my current plan for sandboxing CouchJS. (Thanks to Isaac = for his >>>> tips.) >>>>=20 >>>> When it is time to evaluate some code: >>>>=20 >>>> 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 >>>>=20 >>>> The subprocess can also give extra sandboxing, such as chroot() if >>>> available. >>>>=20 >>>> 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. >>>>=20 >>>> That is my plan. No idea how well it will work. >>>>=20 >>>> -- >>>> Iris Couch >>>=20 >>>=20 >>>=20 >>> Too much kool-aid imo :) >>>=20 >>> 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. >>=20 >> Alternatively, if the above works and is necessary (modulo Klaus=92s >> 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. >=20 > 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. >=20 > 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=92t 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? >>=20 >> Yeah, I=92d love to see that too. >>=20 >>=20 >>> 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. >>=20 >> It=92d be great to have this as a fallback solution! If we eventually = can >> do away with all the C code, the better :) >=20 > 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. >>=20 >> It works fine for Chrome on mobile :) >=20 > 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=92t 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=92d say :) Cheers Jan --=20