couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Hayton" <>
Subject RE: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Mon, 08 Feb 2010 21:48:26 GMT
I agree with Jan.  The goal should be to achieve the best design possible at
this point.  (Not saying Brian's idea is better that what Chris has
committed because I don't have the knowledge to really know either way.) The
point is authorization is a really important "feature" and we shouldn't
really be worrying about existing client libraries prior to a 1.0 release
imho.  Getting it right is much more important.  I am starting to get
concerned about the current plans regarding authorization and releasing 1.0,
but I guess I should reply to Damien's thread about that.  

James Hayton

-----Original Message-----
From: Jan Lehnardt [] 
Sent: Saturday, February 06, 2010 11:38 AM
Subject: Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)

On 6 Feb 2010, at 10:52, Chris Anderson wrote:

> On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler <> wrote:
>> A thought.
>> The current security model requires you spread information in three
>> _readers (has access to database); _security (for controlling updates);
>> _admins (can update security and ddocs)
>> What if this was replaced by a single resource, _security, structured
>> this?
>>   {
>>     "names":{
>>       "foo":[],
>>       "bar":["_admin"]
>>     },
>>     "roles":{
>>       "baz":["doctor"]
>>     }
>>     "otherstuff"
>>   }
>> You get reader access if your name or role appears as key in the relevant
>> section, regardless of the value.  So [] means reader only.  You get
>> access if the value contains "_admin". Other rights are available for the
>> application to use, and may affect validate_doc_update.
>> The reasons I propose this are as follows:
>> 1. it's extensible without having to change the DB structure again
>> 2. application-specific rights can be administered in the same way as
>>   couchdb system rights
>> 3. futon can display this clearly - a list of names and a list of roles,
>>   each with their rights shown next to it
>> 4. a hash key is quicker to look up for access control than an array scan
>> However it retains the current fundamental design, which is that the
>> are stored in a resource within the database, which is not a document.
>> Thoughts?
>> What I've really done is to flip things around, so that
>>    "readers":["name1","name2"]
>>    "admins":["name3"]
>> becomes
>>    {"name1":["reader"], "name2":["reader"], "name3":["admin"]}
>> But doing that also makes it easier to add a future auth model where
>> are stored in a more scalable way (e.g. as separate user documents or in
>> external LDAP database), where such information is keyed by username or
>> role.
> I'm curious how this model supports the common case of a publicly
> accessible database with administrators?
> As far as replacing the _admins _readers and _security database values
> with single complex value, the only reason I didn't do that is that we
> already have a bunch of client libraries that know about _admins. The
> underlying storage treats it all as one object. I don't think it
> matters either way, but I lean toward the status quo because that is
> code that has already been written.

I think this notion is dangerous. If we can opt for a better design, now
is the time to do it.


> I'd be pretty surprised if the ACLs that ship with 0.11 are
> significantly different from what I committed last week.
> Can you explain your application needs? I'm pretty sure that the
> current ACLs can support them. But if you have a common use case falls
> out side what can be done with readers / admins / validations, maybe
> there are minimal tweaks we can do to make it easier for you.
> Chris
>> Regards,
>> Brian.
> -- 
> Chris Anderson

View raw message