couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Sat, 06 Feb 2010 18:52:57 GMT
On Sat, Feb 6, 2010 at 1:58 AM, Brian Candler <B.Candler@pobox.com> wrote:
> A thought.
>
> The current security model requires you spread information in three places:
> _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 like
> 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 admin
> 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 rights
> 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 rights
> are stored in a more scalable way (e.g. as separate user documents or in an
> 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'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
http://jchrisa.net
http://couch.io

Mime
View raw message