On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <j...@apache.org> wrote: > > On Feb 4, 2013, at 11:53 , Benoit Chesneau <bchesn...@gmail.com> wrote: > >> On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith <j...@iriscouch.com> wrote: >>> >>> On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau <bchesn...@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. > > > >> 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 :) >
