Re: Branch to switch from SpiderMonkey to Node.js

[Noah Slater <ns...@apache.org>]

Jason, what's the status of this work now? I am very excited about
the possibilities...


On 5 February 2013 08:39, Jason Smith <jh...@iriscouch.com> wrote:

> Can we please discuss this when I have running code to talk about?
>
> I mentioned my idea but I have not tried it yet. I agree with Benoit,
> forking subprocesses feels like a hack. But without working code, it is
> hard to judge cost vs. benefit.
>
>
> On Tue, Feb 5, 2013 at 7:26 AM, Benoit Chesneau <bc...@gmail.com>
> wrote:
>
> > On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt <ja...@apache.org> wrote:
> > >
> > > On Feb 4, 2013, at 18:47 , Benoit Chesneau <bc...@gmail.com>
> wrote:
> > >
> > >> On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <ja...@apache.org> wrote:
> > >>>
> > >>> On Feb 4, 2013, at 11:53 , Benoit Chesneau <bc...@gmail.com>
> > wrote:
> > >>>
> > >>>> On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith <jh...@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?
> >
> > 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
> >
>
>
>
> --
> Iris Couch
>



-- 
NS