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 887D3EF35 for ; Mon, 4 Feb 2013 11:11:01 +0000 (UTC) Received: (qmail 43249 invoked by uid 500); 4 Feb 2013 11:11:01 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 43221 invoked by uid 500); 4 Feb 2013 11:11:01 -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 43174 invoked by uid 99); 4 Feb 2013 11:10:59 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 04 Feb 2013 11:10:59 +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 (athena.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 11:10:53 +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 50F3E14050 for ; Mon, 4 Feb 2013 12:06:10 +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 12:10:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <5DD875C7-7E61-4FB8-A79C-779363AE5659@apache.org> References: <5102B439.10500@lymegreen.co.uk> <91019D9B-A6AE-4311-9C11-E6001D57293A@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 11:53 , Benoit Chesneau wrote: > 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. 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=20 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=92d 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=92d 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 Best Jan -]-