Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Date: Sun, 24 Feb 2013 00:28:14 +0000 (UTC)
From: "Kevin Gaudin (JIRA)" <jira@apache.org>
To: dev@couchdb.apache.org
Message-ID: <JIRA.12523508.1316399652553.329097.1361665694565@arcas>
In-Reply-To: <JIRA.12523508.1316399652553@arcas>
References: <JIRA.12523508.1316399652553@arcas>
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=13585238#comment-13585238 ] 

Kevin Gaudin commented on COUCHDB-1287:
---------------------------------------

Hi,

I would really love this feature to be available too.
My main concern is that the current documentation let me think that this was already possible:

{quote}
If both the names and roles fields of either the admins or members properties are empty arrays, it means the database has no admins or members. Having no admins, only server admins (with the reserved _admin role) are able to update design document and make other admin level changes. Having no members, any user can write regular documents (any non-design document) and read documents from the database.

Note: If there are any member names or roles defined for a database, then only authenticated users having a matching name or role are allowed to read documents from the database (or do a GET /db_name/ call).
{quote}
[From the Wiki|http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization]

The first paragraph states that 'Having no members, any user can WRITE [...] and READ', then the note explains that with members set 'only authenticated users [...] are allowed to READ'. What about WRITE?

I am a newcomer in the CouchDB community and as a fresh CouchApp developer ([Acralyzer|http://github.com/ACRA/acralyzer]), the security model of CouchDB is what has been puzzling me the most (and I knew nothing about document based databases and MapReduce).

If this "write-only" mode ever comes integrated in CouchDB, please make it something simple to understand:
  * A "dropbox" flag that would instantly prevent members to read from a DB is not simple to understand.
  * If I'm not allowed to read some data, I'm supposed to get a 401 error and not an empty or null 200 OK.

I really liked in this thread [~jhs]'s idea of a _security.readers and _security.writers roles definition. The idea of an execute-only database is interesting too to allow some users to access only to the higher levels of the database and not its internals.

I'm loving CouchDB so far but its fuzzy access policy sometimes makes me regret this choice for Acralyzer. Reading today that you were so close to an agreement a year ago is both encouraging (it might come someday!) and disappointing (none of both proposed implementations got merged after 1 year).

Come on guys, I'm sure you can find a great solution! ;-)


> 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: 1.2
>            Reporter: Jason Smith
>            Priority: Minor
>         Attachments: 0001-fake-db-infos-when-dropbox-true-and-the-user-isn-t-a.patch, 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch, 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch, A_0001-Refactor-reader_acl-test-functions-into-a-loop.patch, A_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch, A_0003-Allow-non-member-writes-if-_security.members.allow_a.patch, B_0001-Refactor-reader_acl-test-functions-into-a-loop.patch, B_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch, B_0003-Allow-non-member-updates-if-_security.members.allow_.patch
>
>
> 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.
> 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira