You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by "Jason Smith (JIRA)" <ji...@apache.org> on 2011/09/19 04:36:08 UTC
[jira] [Created] (COUCHDB-1287) Inbox Database ("write-only" mode)
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
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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Tyler Johnson (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284085#comment-13284085 ]
Tyler Johnson commented on COUCHDB-1287:
----------------------------------------
Hey folks. Just wondering whatever happened with this. Looks like it was well on track.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13108407#comment-13108407 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
@jason Thanks for the implementation patch. I had a quick look about it. But indeed couch_db:* isn't an appropriate place for that imo, it shouldn't know anything about #httpd{} imo, passing it in the req option is awkward.
Maybe we could go to a simpler way ? I was thinking we could allows any readers to do anything but just accept PUT /db/docid and POST /db {...} so no handlers at alls. Which make the test easier imo since you only have to test for "<<"_", _/binary>>. Also rewrite should be disabled for non readers.
Thoughts?
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "kowsik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107602#comment-13107602 ]
kowsik commented on COUCHDB-1287:
---------------------------------
Just a dumb question, that maybe outside the scope of this write-only mode. Is there a way to use the update/validate handlers to rate-limit and or restrict the writes in some ways? Given the writes are effectively coming from an untrusted source, it won't take long to fill the disk *very* quickly.
> 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
>
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153408#comment-13153408 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
@Jason
I'm not sure what is the intention of the patch reading the code. An inbox db or rather a dropbox db should only accept doc creation, then only admins of the db or eventually readers can read them. Here it seems that you can still have a design doc to handle some actions which could pretty dangerous.
Second, I think testing methods based on paths is awkward. If people are using modules or externals, it means that they have to test by themselves if the method is allowed or not which could become a problem. I think a dropbox db should be handle at db level and not HTTP level.
> 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: 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-1287:
---------------------------------
Attachment: A_0003-Allow-non-member-writes-if-_security.members.allow_a.patch
A_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch
A_0001-Refactor-reader_acl-test-functions-into-a-loop.patch
Proposed implementation attached.
## Notes
It would be nice to have _security.readers, _security.writers, and maybe sugar _security.members which implicitly populates both. A write-only DB would have _security.readers = {}, security.writers.roles = ["_anonymous"]. However this patch maintains compatibility with the 1.x codebase. (I tagged it v2.0 because v1.3 is not an option.)
The patch is not correct. Really, couch_db:open is an inappropriate place to assess authorization. Couch must know what the request will do before it determines authorization. It is unsafe to evaluate permission until execution enters the ultimate, true request handler. (Note that couch_db:check_is_admin/1 is sprinkled everywhere. Same deal.)
A more correct patch is more substantial; but substantial code changes is itself a security risk. I opted for the simpler way: whitelist a few good requests based on the method #httpd.path_parts. IMO, this implementation is fail-safe. Unexpected changes or execution isn't likely to grant access. (The couch_db:check_is_admin/1 stuff is fail-unsafe; we must remember to call it every time we change the code.)
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Jason Smith (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-1287:
---------------------------------
Description:
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
was:
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
Affects Version/s: (was: 2.0)
1.2
Pardon. Cleaning and tagging for (hopefully) v1.2.
> 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: 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Benoit Chesneau (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: 0001-fake-db-infos-when-dropbox-true-and-the-user-isn-t-a.patch
fake db infos when dropbox=true and the user isn't authorized. This patch is done on top of 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch
All sizes and counts informations are set to 0 so an unauthorized user view the db as empty. Should fix last issue raised by @jason about the db_info minor security.
$ curl -XGET http://localhost:5984/testdb
{"db_name":"testdb","doc_count":0,"doc_del_count":0,"update_seq":0,"purge_seq":0,"compact_running":false,"disk_size":0,"data_size":0,"instance_start_time":"1321948511448569","disk_format_version":6,"committed_update_seq":0}
$ curl -XGET http://admin:test@localhost:5984/testdb
{"db_name":"testdb","doc_count":1,"doc_del_count":0,"update_seq":2,"purge_seq":0,"compact_running":false,"disk_size":8283,"data_size":279,"instance_start_time":"1321948511448569","disk_format_version":6,"committed_update_seq":2}
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154994#comment-13154994 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
I see. You return 200 OK for a non-member query to /db.
My feeling is that admin-only access to a dropbox db is not useful. That is why my number 1 requirement is that everything stays the same as before and that is confirmed in my test suite.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Randall Leeds (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153978#comment-13153978 ]
Randall Leeds commented on COUCHDB-1287:
----------------------------------------
I'm pretty sure you two won't actually hold a grudge, but try to be more civil. I'd really rather outside observers not think we all hate each other in this community.
I've been super busy lately, or I'd offer a complete review myself. It sounds like you're close to reconciling your expectations, though, and that you may both be writing to the same feature. I agree with the approach of Benoit's patch more, though, re: the level at which authorisation is controlled.
Benoit, can you put it on a branch along with Jason's tests? I think if you can get your patch to pass his tests we'll be a lot closer to landing this.
> 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, 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153991#comment-13153991 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
I hope outside observers would see a spirited debate, neither nasty nor personal.
Benoit, I have no -1 veto power. However I hope to hear a response to my critique: special-case "dropbox" handling must be sprinkled all over the code base. We cannot prove that this feature is 100% secure; we can only make as many unit tests as possible, to be reasonably confident.
Authorization should not be decided at the HTTP level; however, in the current code base, that is the only choke-point. Once you couch_db:open(), there are two problems:
1. Read and write access is unrestricted
2. Subsequent code has lost the Req object, so there is no context to decide yes/no
> 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, 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13155790#comment-13155790 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
i return 200 but with a different message. That's expected since you really want to say it's OK to use this resource.
I don't understand the second part. What is it supposed to mean? What is the action you would like to be done?
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154961#comment-13154961 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
* If user is not a member, normally: GET /db -> 401 Unauthorized
* If user is not a member, dropbox: GET /db -> 200 OK, faux data
Is that the idea? Thanks.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153937#comment-13153937 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Hi, Benoit. No offense intended: as I re-read your patch I think you and I are making different features under the same name. The following Bash script clarifies my critique. I think you will agree that either (a) we are working on different things, with a name collision, "dropbox"; or (b) your patch is careless and dangerous.
#!/bin/bash
# Given: admin user "admin" and normal users "amy" and "bob"
# New database
curl -X DELETE http://admin:admin@localhost:5984/db
curl -X PUT http://admin:admin@localhost:5984/db
# Create a document
curl -X PUT http://admin:admin@localhost:5984/db/doc1 -d '{"hello":"world"}'
curl -X PUT http://admin:admin@localhost:5984/db/doc2 -d '{"hello":"world"}'
# Amy is a member. Bob is not.
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}}'
# Amy can open /db
curl --fail http://amy:amy@localhost:5984/db
# Bob cannot open /db
curl --fail http://bob:bob@localhost:5984/db
# Make a dropbox db
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}, "dropbox":true}'
# Member amy cannot get a doc (regression)
curl --fail http://amy:amy@localhost:5984/db/doc1
# Non-member bob can get DB metadata (minor breach)
curl --fail http://bob:bob@localhost:5984/db
# Member amy cannot get _all_docs (regression)
curl --fail http://amy:amy@localhost:5984/db/_all_docs
# Non-member bob can fetch the entire database (major breach)
curl --fail http://bob:bob@localhost:5984/db/_changes?include_docs=true
# Anonymous users can fetch the entire database (major breach)
curl --fail http://localhost:5984/db/_changes?include_docs=true
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107606#comment-13107606 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Kowsik, this has long been a CouchDB DOS vulnerability however inbox databases do not change the situation.
The real world has and needs side-effects. You post a comment. You post a comment. You post a comment; and now there is a CAPTCHA. You fail. You fail. You fail; and now your IP address is blacklisted.
As with many problems, the solution is not too bad with a "2.1-tier" CouchDB architecture. Watch your logs for activity and update either the database _security object, or else the design document with e.g. update rates. Next, validate_doc_update() can simply confirm that this class of update has not exceeded its rate.
In any case, yes, IMHO it is out of scope here.
> 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
>
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Benoit Chesneau (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: (was: 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch)
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Benoit Chesneau (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch
This is an alternative patch handle dropbox db:
Add dropbox: true to security object. Only admins and db admins can read docs. Anyone can post a doc. No test for now I will add it later today. It's already used in refuge.
Here is how it works:
PUT http://localhost:5984/_security -d'{"dropbox": true}'
-H'Content-Type: application/json'
test it :
curl -XPUT 'http://admin:test@127.0.0.1:5984/testdb/1' -d'{"a": 1}'
-H"Content-Type: application/json"
curl -XGET http://127.0.0.1:5984/testdb/1
{"error":"unauthorized","reason":"You are not a db or server admin."}
curl -XGET http://admin:test@127.0.0.1:5984/testdb/1
{"_id":"2","_rev":"1-3975759ccff3842adf690a5c10caee42","a":1}
---
src/couch_mrview/src/couch_mrview_http.erl | 8 ++++-
src/couchdb/couch_db.erl | 49 ++++++++++++++++++++++-----
src/couchdb/couch_db.hrl | 3 +-
3 files changed, 49 insertions(+), 11 deletions(-)
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Benoit Chesneau (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch
oops the patch based on couchdb. replacing previous one which was based on refuge code.
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Jason Smith (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-1287:
---------------------------------
Comment: was deleted
(was: Hi, Benoit. No offense intended: as I re-read your patch I think you and I are making different features under the same name. The following Bash script clarifies my critique. I think you will agree that either (a) we are working on different things, with a name collision, "dropbox"; or (b) your patch is careless and dangerous.
#!/bin/bash
# Given: admin user "admin" and normal users "amy" and "bob"
# New database
curl -X DELETE http://admin:admin@localhost:5984/db
curl -X PUT http://admin:admin@localhost:5984/db
# Create a document
curl -X PUT http://admin:admin@localhost:5984/db/doc1 -d '{"hello":"world"}'
curl -X PUT http://admin:admin@localhost:5984/db/doc2 -d '{"hello":"world"}'
# Amy is a member. Bob is not.
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}}'
# Amy can open /db
curl --fail http://amy:amy@localhost:5984/db
# Bob cannot open /db
curl --fail http://bob:bob@localhost:5984/db
# Make a dropbox db
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}, "dropbox":true}'
# Member amy cannot get a doc (regression)
curl --fail http://amy:amy@localhost:5984/db/doc1
# Non-member bob can get DB metadata (minor breach)
curl --fail http://bob:bob@localhost:5984/db
# Member amy cannot get _all_docs (regression)
curl --fail http://amy:amy@localhost:5984/db/_all_docs
# Non-member bob can fetch the entire database (major breach)
curl --fail http://bob:bob@localhost:5984/db/_changes?include_docs=true
# Anonymous users can fetch the entire database (major breach)
curl --fail http://localhost:5984/db/_changes?include_docs=true)
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13154969#comment-13154969 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
no?
if user is not a member and db is flagged as dropbox : /GET db => appear as empty
if use is admin and db is flagged as dropbox -> /GET db i=> return real db information
Note for now only admins can read a dropbox db. But if it's really needed and wanted
we could add readers too. Thoughts?
- benoît
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153973#comment-13153973 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
Ok i'm starting annoyed. To be clear I'm -1 about an implementation based on paths**. While authentication is done at HTTP level, authorization shouldn't. It should be resource or feature based. Basing auth on paths and methods open the door to a lot of unexpected problems imo. So I proposed an alternative patch to handle a dropbox features where goal is simple :
- allows anyone to post a doc.
- only db admins can read or query these docs.
- a dropbox db looks empty for anyone except for admins.
- be handled at the core level (couch_db or core functions) when possible to make it easier for the dev to handle these topics.
Which is sensibly the same you described. I simplified maybe a little in attempt to make it easier to use and implement.
re the *alternative* patch I posted . _changes is indeed displaying the docids, however this isn't true when you say it's insecure or dangerous. it doesn't display a doc content, it actually return null (see following tests...) and _all_docs return a 401 error . It is incomplete: _changes features like _all_docs should test if the user is an admin first. New patch is coming fixing that.
/testdb return numbers of docs. Not sure why it's a breach here but I can understand the logic. I will again provide a patch fixing that.
Tests:
$ curl -XPUT http://admin:test@localhost:5984/testdb
{"ok":true}
$ curl -XPUT http://admin:test@localhost:5984/testdb/_security -d'{"dropbox": true}'
{"ok":true}
$ curl -XPOST http://localhost:5984/testdb -d'{"k": "v"}' -H'Content-Type: application/json'
{"ok":true,"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","rev":"1-1be5a5c6039dc44fff8d7a6920129496"}
$ curl -XGET http://localhost:5984/testdb/9cee7d60bc1a4e9dbc7584b3f6000f61
{"error":"unauthorized","reason":"You are not a db or server admin."}
$ curl -XGET http://test:test@localhost:5984/testdb/9cee7d60bc1a4e9dbc7584b3f6000f61
{"error":"unauthorized","reason":"You are not a db or server admin."}
$ curl -XGET http://localhost:5984/testdb/_all_docs
{"error":"unauthorized","reason":"You are not a db or server admin."}
$ curl -XGET http://localhost:5984/testdb/_all_docs -I
HTTP/1.1 401 Unauthorized
Server: CouchDB/1.3.0a-b4295e6-git (Erlang OTP/R14B04)
Date: Mon, 21 Nov 2011 04:03:25 GMT
Content-Type: text/plain; charset=utf-8
Content-Length: 70
$ curl -XGET http://admin:test@localhost:5984/testdb/_all_docs
{"total_rows":1,"offset":0,"rows":[
{"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","key":"9cee7d60bc1a4e9dbc7584b3f6000f61","value":{"rev":"1-1be5a5c6039dc44fff8d7a6920129496"}}
]}
$ curl -XGET http://localhost:5984/testdb/_changes
{"results":[
{"seq":2,"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","changes":[{"rev":"1-1be5a5c6039dc44fff8d7a6920129496"}]}
],
"last_seq":2}
Benoits-MacBook-Air:~ benoitc$ curl -XGET http://localhost:5984/testdb/_changes?include_docs=true
{"results":[
{"seq":2,"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","changes":[{"rev":"1-1be5a5c6039dc44fff8d7a6920129496"}],"doc":null}
],
"last_seq":2}
$ curl -XGET http://admin:test@localhost:5984/testdb/_changes?include_docs=true
{"results":[
{"seq":2,"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","changes":[{"rev":"1-1be5a5c6039dc44fff8d7a6920129496"}],"doc":{"_id":"9cee7d60bc1a4e9dbc7584b3f6000f61","_rev":"1-1be5a5c6039dc44fff8d7a6920129496","k":"v"}}
],
"last_seq":2}
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jason Smith updated COUCHDB-1287:
---------------------------------
Attachment: B_0003-Allow-non-member-updates-if-_security.members.allow_.patch
B_0002-Refactor-the-actual-read-check-out-of-the-member-che.patch
B_0001-Refactor-reader_acl-test-functions-into-a-loop.patch
Second (series B) patch set. Differences from series A:
1. Do not send an #httpd{} to couch_db:open/2. Instead, send only the userCtx (as before) plus the method and path_parts.
2. Allow nonmember POST /db
3. Allow PUT and POST to _rewrites. (If we decide that is unsafe we can negate the assertions.)
> 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, 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.
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153432#comment-13153432 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Thanks, Benoit. I avoid the word "dropbox" because of confusion with the folder sync service. What would CouchDB users expect when enabling a "dropbox" flag. Jan proposed "allow_anonymous_writes" because it is clear.
What is the intention of the patch? The most direct answer is the first and second paragraph of this issue description: to send a private message from user A to user B. Without an inbox db, the solution is a shared db for every combination of users, which is (1) impractical, and (2) not scalable. Note also requirement 3: All updates are still subject to validate_doc_update().
What is going on with your example? Querying /_security gives me illegal_database_name. Did you mean /testdb/_security? This feature is to *suspend the security rules*. We must be attentive to detail.
I am interested in your idea about doing this at at the DB level. I avoided this for a debatable reason: I wanted a minimal patch, easy to understand, changing as little as possible. My core code is 20 lines of focused code. It's all in one place. In our brains, it has locality of reference. But I invite you to defend your security trade-off. Now "dropbox-nature" must be considered throughout the code base, even view handlers. Is it easy to get it right? Well, you got it wrong. Make /testdb private by adding a members list. But a database member can query /testdb but not /testdb/_all_docs. Worse, anonymous users can query /testdb! They can see the doc_count and other details. That is a regression. What's going on? I think we are building different, unrelated features, in which case maybe yours can go in a new ticket?
My patch set includes 50 tests demonstrating what may happen and what may not happen. I included an analysis of the patch's security implications. How about yours? I am thankful for your review. No doubt, you are also sensitive to my frustration: I work hard to contribute to CouchDB, only to see (for the second time) a bigwig committer swoop down, make a quick critique, and post a half-hearted rewrite, showing no evidence of equivalent thoughtfulness and deliberation.
But where are these modules and externals which I have broken? Are they under the Apache CouchDB project? Is there a plugin policy which I have violated? I am not yet persuaded by vague invocations of externals or module authors. (What is a "module" author anyway?) I am intrigued! But not yet persuaded. It sounds like a convenient hypothetical hurdle.
Agreed! Testing based on paths is awkward. But: Pattern matching request paths is the fundamental architecture of CouchDB 1.x. Why does that disqualify new functionality? Plugin authors like me[1] already tackle the problem that _admin is the assumed privilege level.
I find Paul's (anticipated) criticism more compelling: security. My initial implementation was based on HTTP verbs and it was inadequate. Thus, to answer Paul: yes, I am pattern matching; but notice that the patterns are for *approval*, any non-match, anything unexpected, anything except those situations we have explicitly greenlighted, falls back to the current execution path. So, I share your concern completely, but I hope I've shown that I thought it through, and I consider the risk worthwhile.
Committers: you are the stewards of a code base built upon pattern matching paths, manually running couch_db:check_is_admin/1 for every possible privileged query. How can you argue against my whitelisted, fail-safe design with a straight face? :)
[1]:
https://github.com/iriscouch/browserid_couchdb
https://github.com/iriscouch/futon_couchdb
https://github.com/iriscouch/pingquery_couchdb
https://github.com/iriscouch/die_couchdb
https://github.com/iriscouch/cgi_couchdb
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153445#comment-13153445 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
@jason about
""" No doubt, you are also sensitive to my frustration: I work hard to contribute to CouchDB, only to see (for the second time) a bigwig committer swoop down, make a quick critique, and post a half-hearted rewrite, showing no evidence of equivalent thoughtfulness and deliberation. """
I put a comment previously here about what I was thinking, ie using couch_db:*. This alternative patch implement it. It exists in refuge base code and is already used by some that's why I'm ***proposing*** it. Posting a patch don't assure about the result. Also proposing alternative patch with different implementations are common in the opensource world.
> 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
[jira] [Updated] (COUCHDB-1287) Inbox Database ("write-only" mode)
Posted by "Benoit Chesneau (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Benoit Chesneau updated COUCHDB-1287:
-------------------------------------
Attachment: 0001-handle-dropbox-db.-Add-dropbox-true-to-security-obje.patch
patch fixing _changes handling. It now return a 401 error when your not allowed to access it :
$ curl -XGET http://localhost:5984/testdb/_changes
{"error":"unauthorized","reason":"You are not a db or server admin."}
$ curl -XGET http://admin:test@localhost:5984/testdb/_changes?include_docs=true
{"results":[
{"seq":2,"id":"9cee7d60bc1a4e9dbc7584b3f6000f61","changes":[{"rev":"1-1be5a5c6039dc44fff8d7a6920129496"}],"doc":{"_id":"9cee7d60bc1a4e9dbc7584b3f6000f61","_rev":"1-1be5a5c6039dc44fff8d7a6920129496","k":"v"}}
],
"last_seq":2}
another patch is coming to solve db_info
> 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, 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13107666#comment-13107666 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
@kowsic that's another topic. But indeed you can use validate update function to forbid doc insertion. You can do it by checking the user doc. Throttling protections and such however can be added using authenticate module eventually or any other system.
> 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
>
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Benoit Chesneau (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153982#comment-13153982 ]
Benoit Chesneau commented on COUCHDB-1287:
------------------------------------------
@randall sure, that was my intention. I will do in the morning (on it right now) .
@jason I will aslo fix the issues you raised
> 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, 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153936#comment-13153936 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
Hi, Benoit. No offense intended: as I re-read your patch I think you and I are making different features under the same name. The following Bash script clarifies my critique. I think you will agree that either (a) we are working on different things, with a name collision, "dropbox"; or (b) your patch is careless and dangerous.
#!/bin/bash
# Given: admin user "admin" and normal users "amy" and "bob"
# New database
curl -X DELETE http://admin:admin@localhost:5984/db
curl -X PUT http://admin:admin@localhost:5984/db
# Create a document
curl -X PUT http://admin:admin@localhost:5984/db/doc1 -d '{"hello":"world"}'
curl -X PUT http://admin:admin@localhost:5984/db/doc2 -d '{"hello":"world"}'
# Amy is a member. Bob is not.
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}}'
# Amy can open /db
curl --fail http://amy:amy@localhost:5984/db
# Bob cannot open /db
curl --fail http://bob:bob@localhost:5984/db
# Make a dropbox db
curl -X PUT http://admin:admin@localhost:5984/db/_security -d '{"members":{"names":["amy"]}, "dropbox":true}'
# Member amy cannot get a doc (regression)
curl --fail http://amy:amy@localhost:5984/db/doc1
# Non-member bob can get DB metadata (minor breach)
curl --fail http://bob:bob@localhost:5984/db
# Member amy cannot get _all_docs (regression)
curl --fail http://amy:amy@localhost:5984/db/_all_docs
# Non-member bob can fetch the entire database (major breach)
curl --fail http://bob:bob@localhost:5984/db/_changes?include_docs=true
# Anonymous users can fetch the entire database (major breach)
curl --fail http://localhost:5984/db/_changes?include_docs=true
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13113964#comment-13113964 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
I published the patch set as a branch in GitHub.
https://github.com/jhs/couchdb/compare/trunk...inbox
The sole non-housekeeping commit is https://github.com/jhs/couchdb/commit/56a373f
> 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, 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.
> 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/COUCHDB-1287?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13153994#comment-13153994 ]
Jason Smith commented on COUCHDB-1287:
--------------------------------------
When writing the patch, I had in mind the next feature, with a very similar implementation.
I want to implement an execute-only database. Non-members may not do anything except _show, _list, and _update. Thus, Couch app developers would have complete per-document authorization control. Execute-only can also support a reference implementation of Chris's _acl idea.
I hope that, whatever implementation sticks, it can blaze the trail for similar exceptions to the traditional _security requirements.
> 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, 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
[jira] [Commented] (COUCHDB-1287) Inbox Database ("write-only"
mode)
Posted by "Jason Smith (JIRA)" <ji...@apache.org>.
[ 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