Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Mon, 19 Sep 2011 03:22:09 +0000 (UTC)
From: "Jason Smith (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: 
 <1111771669.40984.1316402529197.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1042454867.40917.1316399768852.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
 mode)
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107606#comment-13107606 ] 

Jason Smith commented on COUCHDB-1287:
--------------------------------------

Kowsik, this has long been a CouchDB DOS vulnerability however inbox databases do not change the situation.

The real world has and needs side-effects. You post a comment. You post a comment. You post a comment; and now there is a CAPTCHA. You fail. You fail. You fail; and now your IP address is blacklisted.

As with many problems, the solution is not too bad with a "2.1-tier" CouchDB architecture. Watch your logs for activity and update either the database _security object, or else the design document with e.g. update rates. Next, validate_doc_update() can simply confirm that this class of update has not exceeded its rate.

In any case, yes, IMHO it is out of scope here.

> Inbox Database ("write-only" mode)
> ----------------------------------
>
>                 Key: COUCHDB-1287
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-1287
>             Project: CouchDB
>          Issue Type: New Feature
>          Components: HTTP Interface
>    Affects Versions: 2.0
>            Reporter: Jason Smith
>            Priority: Minor
>
> Currently, we can only grant combined read+write access in the _security object "members" section. A user can either do both or neither. This prevents a very common requirement for couch apps: sending private information from less-privileged users to more-privileged users.
> There is no (reasonable) way to make an "inbox" where anybody may create a doc for me, but only I may read it. An inbox database allows user-to-user, or user-to-admin private messages. (Not only chat messages, but asynchronous notifications--with a per-user inbox, perhaps even service requests and responses.)
> There is no reason _security.members (formerly .readers) should control write access. validate_doc_update() functions do this better.
> I propose a boolean flag, _security.members.allow_anonymous_writes. If it is true, then CouchDB will allow document updates from non-members, giving validate_doc_update() the final word on accepting or rejecting the update.
> Requirements:
> 1. Everything about _security stays the same (backward-compatible)
> 2. If members.allow_anonymous_writes === true, then most PUT and POSTs may proceed
> 3. All updates are still subject to approval by all validate_doc_update functions, same as before.
> The following unit tests cover as much of the functionality as I can think of. (My patch is unfinished but X indicates that I have it working.)
> X Set a database with validate_doc_update, members != []
> X member can write
> X non-member cannot read
> X non-member cannot write
> X non-member cannot write even with .is_ok = true
> X Set inbox mode
> For non-member:
>   X cannot update with .is_ok = false (still subject to validator)
>   X can create with .is_ok = true
>   X can update with .is_ok = true
>   X Can store an attachment with "_attachments"
>   X Can store attachments via direct query
>   X Can delete an attachment via direct query
>   X can delete the doc
>   X can create via an _update function
>   X can update via an _update function
>   * None of these should work:
>     X POST a temp view
>     X POST a view with {"keys":["keys", "which", "exist", "and some which don't"]
>     * POST /db/exist X-HTTP-Method-Override: GET
>     * POST /db/_all_docs
>     * POST /db/_changes
>     * For _show and _list:
>       * POST
>       * OPTIONS
>       * VARIOUS, NONSTANDARD, METHODS (in case Couch allows them later)
>   * These syntax/semantic errors in _security should all fail:
>     * .members.required_to_write = null, [missing], "", 0, true, 1, "false", [false], {false:false}
>     * .required_to_write = false
> These are the known changes to the security model. I consider these all to be either very unlikely in practice, or worth the trade-off.
> * If you write to an inbox DB, you know, for a time, a subset of its documents (but that's the point)
> * An _update function could reveal a document to the user, with or without changing it. However, an admin must install such a misguided update function.
> * You can launch timing attacks to learn information about validate_doc_update
>   * You might discover whether doc IDs exist in the DB or not
>   * You might discover a well-known open source validation function. You can look for bugs in its source code.
> * Zero or more things which Jason can't think of

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira