[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108755#comment-13108755
]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Thanks, Benoit. These are good points.
I agree, really the entire execution path is awkward. It deserves a major
change to clarify and simplify the security architecture. However, do you agree
that such change is not appropriate for the 1.x codebase? That was my feeling,
and that is why I adopted the somewhat awkward code. However, the flaw is not
fatal.
Before this patch, HTTP handlers ask the deeper layer (couch_db:open), "Please
open the database, and here is some request context, user_ctx, to decide about
permission."
After this patch, HTTP handlers ask the deeper layer (couch_db:open), "Please
open the database, and here is some request context, user_ctx, method,
path_parts to decide about permission."
Thus, the patch does not change the situation fundamentally. But you are
correct that couch_db:open should not know about #httpd{}.
What do you think about this instead? It shaves the Options down to only the
necessary information:
couch_db:open(Db, [{user_ctx,UserCtx}, {method,Method},
{path_parts,PathParts}])
This way, couch_db:open does not have to extract the HTTP information itself.
The abstraction barrier is cleaner. We remain foolish (Matt 7:26) but IMO we
can still weather the storm ;)
Finally, why should _rewrite be disabled for non-readers? I rather like your
implementation: completely re-build a request object and re-execute. This
ensures that nobody can sneak past the defenses by using rewrite: every
rewritten request must start from the beginning. For this reason, I do not see
a security objection to _rewrite. Do you object on other grounds? (For example,
if I succeed in a _rewrite request, then I have learned information about the
ddoc)
> 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
>
>
> 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
