couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benoit Chesneau (Commented) (JIRA)" <>
Subject [jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only" mode)
Date Sat, 19 Nov 2011 10:02:51 GMT


Benoit Chesneau commented on COUCHDB-1287:

The alternative patch i propose is 49 insertions, 11 deletions, so it's pretty short too.
. Also i don't care about havin a service named dropbox , the thing is this is a dropbox,
but name can be change if most want, thta's an implementation detail. 

Yes,  it's /testdb/_security . What do you mean by prevent, only admins can used that and
once it's done only admins can change that. Where is the problem. If you want to remove the
security object use, not sure why ..., but it should be a different patch. What I would like
to see is making this security object optionally replicable (for clusters) but that's another
point, another ticket.

I'm not sure why do you mean when you say I got it wrong. Particularly offensive. What do
you mean by query /testdb ? I think you misunderstood the patch. 

The alternative patch forbid anonymous users to query the db which is flagged as dropbox.
Only admins car read it (readers can be added if there is a need to). Since anonymous users
are forbidden they can't access to design docs so the views (a view imply to read the ddoc).
_all_docs is a specific case. It shouldn't be part of couch_mrview in fact but like davisp
said there isn't an easy way to separate it from it since we need to parse parameters and
such. It will be part of another patch but I intend to propose a patch adding all_docs handling
to couch_db module. But _all_docs is forbidden. About the count of db, what's the security
issue here? If there is really an issue, a check could be added to dbinfo function too. But
you should be aware that it will break then some couchdb clients.

So here we have a working dropbox. There is no test for now, but this patch is actually used
in a real project. Like I said I will add tests today. Also technically speaking  this patch
is really simple, it doesn't do much than allowing anonymous writes while preventing reading.

Re security. My criticism are about security too. Testing on path and method is really awkward,
it works "mostly" today, but what about the future?. When speaking about externals and other
things I'm thinking to people that add plugins to couchdb. This expectation should be taken
in consideration. While couchdb can't answers to all needs I see more and more people customizing
it, adding plugins and such. We should support that by providing the right api imo. Also I
don't want to force users to check that they handle correctly a dropbox feature etc which
should be part of the core. That's the point of having it handled at lower level. I'm doing
as much pluging as you do, and the more I work on that part, the more I think the couchdb
core could simplify the life of these external coders. At a community point of view having
more plugins developed is good.
> Inbox Database ("write-only" mode)
> ----------------------------------
>                 Key: COUCHDB-1287
>                 URL:
>             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:!default.jspa
For more information on JIRA, see:


View raw message