[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153432#comment-13153432
]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Thanks, Benoit. I avoid the word "dropbox" because of confusion with the folder
sync service. What would CouchDB users expect when enabling a "dropbox" flag.
Jan proposed "allow_anonymous_writes" because it is clear.
What is the intention of the patch? The most direct answer is the first and
second paragraph of this issue description: to send a private message from user
A to user B. Without an inbox db, the solution is a shared db for every
combination of users, which is (1) impractical, and (2) not scalable. Note also
requirement 3: All updates are still subject to validate_doc_update().
What is going on with your example? Querying /_security gives me
illegal_database_name. Did you mean /testdb/_security? This feature is to
*suspend the security rules*. We must be attentive to detail.
I am interested in your idea about doing this at at the DB level. I avoided
this for a debatable reason: I wanted a minimal patch, easy to understand,
changing as little as possible. My core code is 20 lines of focused code. It's
all in one place. In our brains, it has locality of reference. But I invite you
to defend your security trade-off. Now "dropbox-nature" must be considered
throughout the code base, even view handlers. Is it easy to get it right? Well,
you got it wrong. Make /testdb private by adding a members list. But a database
member can query /testdb but not /testdb/_all_docs. Worse, anonymous users can
query /testdb! They can see the doc_count and other details. That is a
regression. What's going on? I think we are building different, unrelated
features, in which case maybe yours can go in a new ticket?
My patch set includes 50 tests demonstrating what may happen and what may not
happen. I included an analysis of the patch's security implications. How about
yours? I am thankful for your review. No doubt, you are also sensitive to my
frustration: I work hard to contribute to CouchDB, only to see (for the second
time) a bigwig committer swoop down, make a quick critique, and post a
half-hearted rewrite, showing no evidence of equivalent thoughtfulness and
deliberation.
But where are these modules and externals which I have broken? Are they under
the Apache CouchDB project? Is there a plugin policy which I have violated? I
am not yet persuaded by vague invocations of externals or module authors. (What
is a "module" author anyway?) I am intrigued! But not yet persuaded. It sounds
like a convenient hypothetical hurdle.
Agreed! Testing based on paths is awkward. But: Pattern matching request paths
is the fundamental architecture of CouchDB 1.x. Why does that disqualify new
functionality? Plugin authors like me[1] already tackle the problem that _admin
is the assumed privilege level.
I find Paul's (anticipated) criticism more compelling: security. My initial
implementation was based on HTTP verbs and it was inadequate. Thus, to answer
Paul: yes, I am pattern matching; but notice that the patterns are for
*approval*, any non-match, anything unexpected, anything except those
situations we have explicitly greenlighted, falls back to the current execution
path. So, I share your concern completely, but I hope I've shown that I thought
it through, and I consider the risk worthwhile.
Committers: you are the stewards of a code base built upon pattern matching
paths, manually running couch_db:check_is_admin/1 for every possible privileged
query. How can you argue against my whitelisted, fail-safe design with a
straight face? :)
[1]:
https://github.com/iriscouch/browserid_couchdb
https://github.com/iriscouch/futon_couchdb
https://github.com/iriscouch/pingquery_couchdb
https://github.com/iriscouch/die_couchdb
https://github.com/iriscouch/cgi_couchdb
> 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
