On Sat, Jan 26, 2013 at 9:11 AM, Jason Smith <j...@iriscouch.com> wrote:
> Russell, thanks for you comments on the ticket. > > For the record, I fixed some i/o bugs in couchjs and most of the test suite > is passing on my branch now. I have nearly achieved phase 1. > > I think you probably agree, in a situation like this, the only acceptable > approach is the whitelist. I think it might be easy to disable i/o in > Node.js, because it is easy to control what is in scope for the guest code. > Without access to require() or the fs module, how can code perform i/o? > Note, since the stakes are high, we must *confirm* this hypothesis, of > course. > > An interesting exception and challenge for the "no I/O" rule is that of > course the entire implementation of view servers is via message passing > over stdio. > > I agree with your comments about npm. Three points: > > 1. Right, it is inappropriate or out of scope to talk about using > modules/packages/npm from the view server. Besides huge security issues, it > is only marginally useful within the CouchDB 1.x API. So much of the API is > stateless and pure-functional programming. > > 2. One reason I want to try Node.js (rather than V8) is to open the door to > users extending CouchDB and/or building applications with full-on arbitrary > Node.js code--totally separate from the view server API: maybe a version > 2.x discussion. > > Nothing stop us to open the door to the users by using v8. v8 doenst' share anything with the system by default. Imo it would be better to start from 0 instead of hacking nodejs to remove features that exactly define nodejs. nodejs this is v8 + a bunch of code to access to IO. I'm afraid that it can be really difficult to remove features rather than adding them in a way you can quietly handle permissions. So we could have something àla chromeapps where you allows explicitely an app to access to some parts of the system or not. > 3. Besides security, if someone could demonstrate a great performance gain > by e.g. embedding V8 in Erlang then that would be a strong argument against > Node.js. I am not holding my breath. We could extend the view server > protocol to "upgrade" from stdio to SysV or POSIX shared memory and get a > similar performance boost. The Erlang side would be a NIF and the Node side > would be a native module--so, C code talking to C code. > > We don't need to be so ugly. The system already give use some possibilities to have more concurrency. Instead of using STDIO which where everything is serialized we could use for example a TCP or UNIX socket. You don't want to use shared memory, it can be very problematic.
