[
https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13585238#comment-13585238
]
Kevin Gaudin commented on COUCHDB-1287:
---------------------------------------
Hi,
I would really love this feature to be available too.
My main concern is that the current documentation let me think that this was
already possible:
{quote}
If both the names and roles fields of either the admins or members properties
are empty arrays, it means the database has no admins or members. Having no
admins, only server admins (with the reserved _admin role) are able to update
design document and make other admin level changes. Having no members, any user
can write regular documents (any non-design document) and read documents from
the database.
Note: If there are any member names or roles defined for a database, then only
authenticated users having a matching name or role are allowed to read
documents from the database (or do a GET /db_name/ call).
{quote}
[From the
Wiki|http://wiki.apache.org/couchdb/Security_Features_Overview#Authorization]
The first paragraph states that 'Having no members, any user can WRITE [...]
and READ', then the note explains that with members set 'only authenticated
users [...] are allowed to READ'. What about WRITE?
I am a newcomer in the CouchDB community and as a fresh CouchApp developer
([Acralyzer|http://github.com/ACRA/acralyzer]), the security model of CouchDB
is what has been puzzling me the most (and I knew nothing about document based
databases and MapReduce).
If this "write-only" mode ever comes integrated in CouchDB, please make it
something simple to understand:
* A "dropbox" flag that would instantly prevent members to read from a DB is
not simple to understand.
* If I'm not allowed to read some data, I'm supposed to get a 401 error and
not an empty or null 200 OK.
I really liked in this thread [~jhs]'s idea of a _security.readers and
_security.writers roles definition. The idea of an execute-only database is
interesting too to allow some users to access only to the higher levels of the
database and not its internals.
I'm loving CouchDB so far but its fuzzy access policy sometimes makes me regret
this choice for Acralyzer. Reading today that you were so close to an agreement
a year ago is both encouraging (it might come someday!) and disappointing (none
of both proposed implementations got merged after 1 year).
Come on guys, I'm sure you can find a great solution! ;-)
> 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
