couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jason Smith (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1894) Add experimental NodeJS query server
Date Thu, 26 Sep 2013 04:43:05 GMT


Jason Smith commented on COUCHDB-1894:

[~wohali] This code does explicitly restrict view code to the same degree as couchjs, so I
think we are good there.

[~chewbranca] I think we are in agreement about the process of analysis. I am also very sensitive
about security. So let's identify all that go into it and I think we will reach the same conclusion.

First of all, I seriously doubt that the current couchjs "sandbox" is secure. It has not undergone
a sustained attack, nor even an audit to my knowledge. So I do not actually want to compare
node-couchjs vs. traditional couchjs, I would rather compare node-couchjs vs $something_we_agree_is_acceptable.
For example, today, it is trivial to leak state between executions of a map function (just
set a global variable). To me, that breaks the idea of a proper sandbox.

Next, couchjs has libcurl compiled in which can access the filesystem via file:/// URLs. But
also, if we are talking about hypothetical exploits, you do not need file i/o compiled into
couchjs to do i/o. An (again, hypothetical) shell code attack could make system calls to do

This makes me think two thoughts:

1. We are really talking about the threat from *trusted* code running, since it can only be
created by an administrator in the first place. IMO, the threat is not from malicious attackers
but from bugs deployed by the admin. This is why the "global variable" problem of today's
couchjs has never been a real-world issue.

2. Rather than hypothetical threats ("what functionality is compiled in?"; "How many angels
can dance?") I would like to focus on practical issues to address. This is definitely marked
experimental and I agree it needs improvement before production use. But I'd rather not just
say "fasifiability problem" and throw up my hands; I want to make reasoned, rational, real-world
assessments about how far we can go with this branch.

(I would also point out that the falsifiability argument applies to today's couchjs, yet nobody
is clamoring to remove it.)

So for example, whitelisting require() is irrelevant I think. Code in the view server does
not have access to the Node.js require function at all. (There is a "require" function however
it is the standard couchapp thing, to load code from within a design document:
> Add experimental NodeJS query server
> ------------------------------------
>                 Key: COUCHDB-1894
>                 URL:
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: JavaScript View Server
>            Reporter: Jan Lehnardt
> Let’s clean up and merge Jason Smith’s Node.js query server into ASF land and ship
it as opt-in and experimental.
> I’ve prepared a branch that does the following:
>  - remove fancy extra features like app server handlers and the visual debugger support
for now
>  - make it a drop-in replacement for couchjs
>  - bundle the code in src/couchjs-node
>  - add a new query server language “nodejs” that people can use
>  - include sandbox.js from (not hooked up
> The query server is not installed by default and users can install them in two ways:
> 1. from source:
>     $ cd src/couchjs-node
>     $ npm link
> 2. from NPM:
>     $ npm install couchjs # add @1.x.x for once the module mirrors CouchDB version numbers
for forward compat)
> And then they can uncomment and update the [query_server] line in local.ini.
> * * *
> Open work items on the view server:
>  - make it work with CLI tests
>  - fix remaining test cases in web test runner
>  - hook up sandbox.js from

This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see:

View raw message