[ 
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

        

Reply via email to