couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: DB ACLs (was Re: 0.11 Release / Feature Freeze for 1.0)
Date Sat, 06 Feb 2010 09:58:56 GMT
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


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.


What I've really done is to flip things around, so that



    {"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



View raw message