Jason, what's the status of this work now? I am very excited about the possibilities...
On 5 February 2013 08:39, Jason Smith <[email protected]> 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 <[email protected]> > wrote: > > > On Mon, Feb 4, 2013 at 6:58 PM, Jan Lehnardt <[email protected]> wrote: > > > > > > On Feb 4, 2013, at 18:47 , Benoit Chesneau <[email protected]> > wrote: > > > > > >> On Mon, Feb 4, 2013 at 12:10 PM, Jan Lehnardt <[email protected]> wrote: > > >>> > > >>> On Feb 4, 2013, at 11:53 , Benoit Chesneau <[email protected]> > > wrote: > > >>> > > >>>> On Thu, Jan 31, 2013 at 5:54 PM, Jason Smith <[email protected]> > > wrote: > > >>>>> > > >>>>> On Thu, Jan 31, 2013 at 4:34 PM, Benoit Chesneau < > > [email protected]>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
