[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch
This is an alternative patch handle dropbox db:
Add dropbox: true to security object. Only admins and db admins can read docs.
Anyone can post a doc. No test for now I will add it later today. It's already
used in refuge.
Here is how it works:
PUT http://localhost:5984/_security -d'{"dropbox": true}'
-H'Content-Type: application/json'
test it :
curl -XPUT 'http://admin:[email protected]:5984/testdb/1' -d'{"a": 1}'
-H"Content-Type: application/json"
curl -XGET http://127.0.0.1:5984/testdb/1
{"error":"unauthorized","reason":"You are not a db or server admin."}
curl -XGET http://admin:[email protected]:5984/testdb/1
{"_id":"2","_rev":"1-3975759ccff3842adf690a5c10caee42","a":1}
---
src/couch_mrview/src/couch_mrview_http.erl | 8 ++++-
src/couchdb/couch_db.erl | 49 ++++++++++++++++++++++-----
src/couchdb/couch_db.hrl | 3 +-
3 files changed, 49 insertions(+), 11 deletions(-)
> 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-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:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
