couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Reader ACLs
Date Mon, 18 Jan 2010 18:11:47 GMT
On Mon, Jan 18, 2010 at 4:59 AM, David Goodlad <> wrote:
> On Mon, Jan 18, 2010 at 8:31 PM, Brian Candler <> wrote:
>> I have tried out the readeracl branch, and I have the following
>> observations.
> [snip]
> My biggest 'take away' from all of those observations is a feeling
> that I've had for quite some time, that security should be the
> responsibility of the application in a given database. That, to me,
> means managing it through regular and/or design documents. I know this
> doesn't fit the existing scheme; but the existing scheme seems quite
> limiting and somewhat naive of many potential applications.

The reader ACLs are just a clone of the db-admin lists we've had for a
long time. The goal is to do the simplest thing that could possibly

As far as I can tell, the only case these reader ACLs + the planned
security document can't handle gracefully is the case where the
security document starts to get too large (in which case you can
probably shrink it again by creating a new server-level role.)

I know it's not super flexible, but if we were to go add a bunch of
texture to it, we'd probably end up creating as much trouble for the
80% case as we solve for the remaining 20%

> The idea that security (authorization, maybe not authentication) can
> be managed by the app itself, with some combination of regular and/or
> design documents, seems to fit very well with the existing idea of
> design documents. Authorization for writing is already being handled
> by convention in the validation function, which is part of design
> docs, so why not take that idea further and extend it to reading?
> App developers should be free to implement a wide range of security
> mechanisms without having to resort to putting software (a proxy) in
> front of couchdb. Couch should take care of authentication in a
> standard way (the cookie auth via lookups on the _users database or
> extensions like oauth etc), then step back and let the app developer
> decide how to do authorization for both read and write operations.
> I've got a few ideas for how this could be implemented.
> First, db-wide read/write/admin access could be determined via a view.
> The view would would emit rows with usernames as keys, and data to be
> used for authorization as the value (or an _id/_rev pair, which would
> use the existing functionality for including/referencing other docs).
> For example, a reader view's map function could look something like
> this:
> function(doc) {
>  if(doc.type == 'user' && !doc.banned) {
>    emit(, doc.roles);
>  }
> }
> The existing validate functions would be given a new parameter (in
> place of the 'security object' as previously discussed) containing the
> value from the view:
> function(newDoc, oldDoc, userCtx, userData) {
>  if(newDoc.type == 'article' && userData.indexOf('editor') == -1) {
>    throw({forbidden: "Only editors can change articles"})
>  }
> }
> These examples use an array of roles, but any data could theoretically
> be passed around, allowing great flexibility.
> I'm not sure of the performance implications of such a scheme, but
> with some reasonable cacheing thanks to the use of views, I'd hope
> that it would not have much of an impact.
> What do you guys think?

There are a few reasons not to have views instead of the security
object. The main one is that validation funcs need to be isolated.
This is for 2 reasons: one is performance on a cluster. Making the
view query for every insert could really slow things down, and if the
view can't be queried for whatever reason, then inserts are blocked.
We try really hard to keep slow / potentially-blocking things out of
the critical path.

The second is that since validations run at replication time as well
as for regular updates, they need to be independent of all other
documents. In a cluster, replication can get out of order (maybe a
comment comes through before its associated blog post) and any ability
to have interdependencies between documents in validation is an
opportunity to create heisenbugs.

I plan to keep on this track, with this kind of Reader access control
for databases. Once it's solid (thanks for the JSON bug finding,
Brian) we should quickly see which use cases this works for.

Re: public-by-default. I think we should keep this setting (instead of
having an all user) and then make it simple in Futon to check a box
when creating a database that says "make this database private" and
then it will add the current user's name to the readers list.

But we don't want to lock people out of databases by default. By
default Couch should continue to work as it has for a long time. We
just want to make it easy to add basic read control.


Chris Anderson

View raw message