[
https://issues.apache.org/jira/browse/COUCHDB-1894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13778473#comment-13778473
]
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 i/o.
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:
https://github.com/apache/couchdb/blob/master/share/server/util.js#L83-L108)
> Add experimental NodeJS query server
> ------------------------------------
>
> Key: COUCHDB-1894
> URL: https://issues.apache.org/jira/browse/COUCHDB-1894
> 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 https://github.com/KlausTrainer/sandbox.js (not
> hooked up yet)
> 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 https://github.com/KlausTrainer/sandbox.js
--
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: http://www.atlassian.com/software/jira
