You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Benoit Chesneau <bc...@gmail.com> on 2011/09/01 17:41:54 UTC

Fwd: Noob security question

forwarding this thread. Maybe we could make things a little more intuitive here?


---------- Forwarded message ----------
From: Benoit Chesneau <bc...@gmail.com>
Date: Thu, Sep 1, 2011 at 3:02 PM
Subject: Re: Noob security question
To: user@couchdb.apache.org


On Thu, Sep 1, 2011 at 2:30 PM, Neil Gibbons <gi...@gmail.com> wrote:
> Hey,
>
> Posted this on stackoverflow.com too, (
> http://stackoverflow.com/questions/7260971/couchdb-iris-couch-noob-security-question),
> which
> led me to the mailing list.
>
> Basically I've been playing with Iris Couch but have come across some
> unexpected behavior.
> I have the following _security set against a test db:
>
> {"admins":{"names":["neil"],"roles":["admin"]},"readers":{"names":["guest"],"roles":["guest"]}}.
>
> When I created a new server admin via Futon:
>
> {"_id":"org.couchdb.user:test2","_rev":"1-084965a94ea3d7a24116f33245a0ef95","name":"test2","type":"user","roles":[]}
>
> This user can read from my test db?
>
> curl -X GET http://test2:test@neil.iriscourchdb.com/test
> curl -X GET http://test2:test@neil.iriscourchdb.com/test/_all_docs
>
> Because neither this users name nor role appear in the _security document
> I'd expect them not to be able to be authorized?
>
>
> Neil
>

I'm also confused. What it happen anyway is:

- The admin created via futon, create an admin user in the ini file.
- This user have admin rights and can see/manage all the dbs
- The  confusing part: a user document is also created but have empty roles.

Imo rather we create all the users in the user db with appropriate
roles, or "super" admins shouldn't appear in it. That's worth a
discussion.

- benoit

Re: Noob security question

Posted by Peter Nolan <pe...@gmail.com>.
Personally I haven't had a need for security so far, but a lot of people
have been asking about the security protocol of couch.  In fact, its almost
always the first question asked by someone unfamiliar with the project.

So making an intuitive, secure, and 'relaxful' security is something that
should be accomplished, so lets start discussing it...

(longest bump ever)

Re: Noob security question

Posted by Benoit Chesneau <bc...@gmail.com>.
bump

On Thu, Sep 1, 2011 at 5:41 PM, Benoit Chesneau <bc...@gmail.com> wrote:
> forwarding this thread. Maybe we could make things a little more intuitive here?
>
>
> ---------- Forwarded message ----------
> From: Benoit Chesneau <bc...@gmail.com>
> Date: Thu, Sep 1, 2011 at 3:02 PM
> Subject: Re: Noob security question
> To: user@couchdb.apache.org
>
>
> On Thu, Sep 1, 2011 at 2:30 PM, Neil Gibbons <gi...@gmail.com> wrote:
>> Hey,
>>
>> Posted this on stackoverflow.com too, (
>> http://stackoverflow.com/questions/7260971/couchdb-iris-couch-noob-security-question),
>> which
>> led me to the mailing list.
>>
>> Basically I've been playing with Iris Couch but have come across some
>> unexpected behavior.
>> I have the following _security set against a test db:
>>
>> {"admins":{"names":["neil"],"roles":["admin"]},"readers":{"names":["guest"],"roles":["guest"]}}.
>>
>> When I created a new server admin via Futon:
>>
>> {"_id":"org.couchdb.user:test2","_rev":"1-084965a94ea3d7a24116f33245a0ef95","name":"test2","type":"user","roles":[]}
>>
>> This user can read from my test db?
>>
>> curl -X GET http://test2:test@neil.iriscourchdb.com/test
>> curl -X GET http://test2:test@neil.iriscourchdb.com/test/_all_docs
>>
>> Because neither this users name nor role appear in the _security document
>> I'd expect them not to be able to be authorized?
>>
>>
>> Neil
>>
>
> I'm also confused. What it happen anyway is:
>
> - The admin created via futon, create an admin user in the ini file.
> - This user have admin rights and can see/manage all the dbs
> - The  confusing part: a user document is also created but have empty roles.
>
> Imo rather we create all the users in the user db with appropriate
> roles, or "super" admins shouldn't appear in it. That's worth a
> discussion.
>
> - benoit
>