couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Per-DB Auth Ideas and Proposal
Date Mon, 14 Sep 2009 10:29:09 GMT
Hi,

On 14 Sep 2009, at 02:19, Adam Kocoloski wrote:
>> As with history, I could see we'd want a document type that is a  
>> hybrid of a regular doc and a _local doc, say _db/ for example,  
>> that can be replicated conditionally with
>>
>> POST /_replicate
>> {source:..,target:...,replicate_db_doc:true}
>
> Interesting idea.  I imagine that in the implementation these would  
> be regular documents, but with pattern-matching filters in the  
> replication framework.

 From my understanding how _local/ docs are implemented, that'd be the  
way to go yes, but I might miss a detail or two.

>
>>> We might take this one step further and allow additional Access  
>>> Control Elements in individual documents.  These ACEs would be  
>>> prepended to the DB ACL and would allow you to specify custom  
>>> authz for a subset of documents in a DB without having to resort  
>>> to path-based regex and editing the DB ACL every time.
>>
>> Sounds complicated. -1
>>
>>> Finally, there's the issue of authz in views.  What privileges  
>>> does the view indexer have?  If a user who is only allowed to read  
>>> some of the documents in the DB is allowed to upload a _design  
>>> document, it seems to me that the views generated from that  
>>> _design document must exclude any forbidden documents.  I guess  
>>> this can work if the _design doc stores the roles of the user who  
>>> saved it.  It seems like a tricky, but solvable problem.
>>
>> So far we don't have the notion per-doc ACL's. So a user can read  
>> all docs in the DB or none, but not some. If we'd go there, I think  
>> users that can modify design docs are higher in the auth* chain  
>> than users that only can read some documents and thus inherit the  
>> role of read-all-docs.
>
> That's true, if per-document ACLs are a -1 as you indicated above  
> then view security becomes far simpler.  Does it mean you're also -1  
> on the path-based regex in the ACL example I wrote?  Because that's  
> just an alternative implementation of per-document ACLs.

To clarify, I'm not -1 ACLs, just the "one step further" ACEs. That  
said, "-1" was a bit strong, your one paragraph description sounded  
complicated to me and I'd rather keep this simple and working well.  
Path-based regex is very powerful and useful (*hugs mod_rewrite*), but  
I'm not sure if that should be part of a _rewrite handler instead of  
the security model.

I.e I can achieve locking down resources by rewriting and  
conditionally rewriting URL requests (mod_rewrite) without tapping  
into any httpd authentication systems. We should think about what  
scenarios we want to support with any upcoming auth* and _rewrite  
systems and make sure we are clear about which system supports which  
scenario and not mix things up.

One of the strengths of CouchDB's design is that is broken down to the  
bare minimum needed to be useful. I'd like to keep the auth* system  
that way. Curt has done some great work collecting discussions and  
related material (http://wiki.apache.org/couchdb/Authentication_and_Authorization 
).

Cheers
Jan
--


Mime
View raw message