incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <>
Subject Re: Per-DB Auth Ideas and Proposal
Date Mon, 14 Sep 2009 00:33:25 GMT
On Sep 13, 2009, at 2:07 AM, Chris Anderson wrote:

>> What are the next steps?
> I think a per-doc reader ACL is a fine place to start.
> If a doc has an element like
> {
> "_id":"football playbook",
> "_rev":"2-a24d12b",
> "access" : {
>    "roles" : ["players"],
>    "users" : ["coach"]
>  },
> }
> or maybe "access" isn't the best name, but the idea should be clear  
> enough

Whatever name we choose, I think it should certainly be an underscore- 
prefixed reserved name.  I'm partial to _acl myself.

> I played around with read & write access lists but write can be
> handled by the validation function so it's not necessary. The only
> reason we have to standardize this stuff at all is to avoid a
> Spidermonkey call on read, so we can keep it as simple as possible.

I think we should implement both read and write restrictions using  
these ACLs.  Both for performance reasons and because it'd be weird if  
reader and writer lists were configured in such different fashions.

If calling out to Spidermonkey on reads isn't as awful of a  
performance hit as I expect it to be then supporting Vlad's  
validate_doc_read proposal would also make sense from symmetry  

> I also thought about adding allow/deny so that eg, everyone but Joan
> could see Joan's surprise party invitation. But that seems to wreck
> havoc with any kind of sane way to make security work with views.

Can you say a little more about this?  How are you envisioning view  
security working with per-document controls?  It seems to me that once  
you have per-doc ACLs view security is already complicated, and you  
might as well go all the way to allow/deny support too.

> The other option is to require views be calculated on the client,
> which means you can punt on view security, and just let read-security
> handle it during replication.


Best, Adam

View raw message