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