[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-1287: --------------------------------- Attachment: B_0003-Allow-non-member-updates-if-_security.members.allow_.patch B_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch B_0001-Refactor-reader_acl-test-functions-into-a-loop.patch Second (series B) patch set. Differences from series A: 1. Do not send an #httpd{} to couch_db:open/2. Instead, send only the userCtx (as before) plus the method and path_parts. 2. Allow nonmember POST /db 3. Allow PUT and POST to _rewrites. (If we decide that is unsafe we can negate the assertions.) > 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 > 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. > 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