[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153443#comment-13153443
]
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: 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
