couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Klaus Trainer (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only" mode)
Date Fri, 22 Feb 2013 22:40:13 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13584778#comment-13584778
] 

Klaus Trainer commented on COUCHDB-1287:
----------------------------------------

As I was recently in need of this feature, I rebased Benoit's current
version of the patch and had a look at it. The patch looks simple and
straight-forward. It checks authorization based on the user context in
the #db record, and it simply differentiates between admins and non-
admins.

So, with Benoit's implementation it is possible to send "private
messages" as anonymous (i.e. unauthenticated) or authenticated non-
admin user to an admin, but it is not possible to send one to someone
who is not an admin. In short, the receiver always has to be an admin.

Although Jason originally proposed a solution that wouldn't require a
receiver to be an admin, I'd propose to keep that constraint for the
following reasons:

* it's less complex from an implementation perspective, i.e., the
  changes that need to be done are more straight-forward and less
  intrusive
* it's less complex from a user perspective.

Here's my list of things that should definitely be done in order to get
this feature ready for a future release (please tell me if you think
something is missing here):

* clarify naming (inbox, dropbox, allow_anonymous_writes, write_only)
* add tests
* add documentation
* reflect the feature in Fa?uton; for instance, add a checkbox in the
  respective "Security" menu.
                
> 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

Mime
View raw message