[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13658726#comment-13658726
]
Klaus Trainer commented on COUCHDB-1287:
----------------------------------------
@[~dch]: Although I like Benoit's implementation and feel confident about its
correctness and usefulness (see my earlier comment), it's not what Jason
proposed here. Note Jason's concern he raised: "My feeling is that admin-only
access to a dropbox db is not useful."
As I don't agree with Jason here, and think that admin-only read access would
definitely be useful, I'd rather like to ask in which regard admin-only read
access were less useful than compared to having read access for admins and
members.
In Jason's implementation all members have the same read access rights for all
documents. Whereas, in Benoit's implementation only admins have read access
rights, and members don't have any additional authorization than compared to
anonymous users. Note that with *both* implementations it would be possible to
add an execute-only authorization (like a UNIX directory permission with only
the executable bit set) feature, where members are able to read-access a
document if they retrieve it by its id, but not otherwise.
> 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
