[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only" mode)

["Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>]

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

Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------

@Jason

I'm not sure what is the intention of the patch reading the code. An inbox db or rather a dropbox db should only accept doc creation,  then only admins of the db or eventually readers can read them. Here it seems that you can still have a design doc to handle some actions which could pretty dangerous.

Second, I think testing methods based on paths is awkward. If people are using modules or externals, it means that they have to test by themselves if the method is allowed or not which could become a problem. I think a dropbox db should be handle at db level and not HTTP level. 
                
> 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: 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira