Devs,

Couch has not had any sort of per-document access control in the past.
This is because it is deemed too much of burden on implementors of
secondary indexers (like GeoCouch, CouchDB Lucene, etc) to enforce
reader control rules in all the indexes. To do it even for the
built-in Map Reduce would waste lots of either space or time compared
to the per-database read access model we have now.

So far we have avoided any sort of reader ACL system. I do not propose
to change any of the above reasoning, but I have a simple idea that
might make reader ACLs feasible. The idea is an alternate
configuration of CouchDB that eschews view indexing in favor of
enforcing an ACL for document readers. So in a full deployment you
might have some databases with views enabled (and per-db access
restricted to the users who are allowed to read Everything in those
dbs, just like today). But you might also have some databases that are
readable by most users (or public), and abide by per-document reader
access control lists for security. In those databases, view access
would be admin-only.

So for instance if I have a private database setup for my message
browsing couchapp to run in, and there is a public database on a
server I trust, that runs reader_acls, then I can set up continuous
replication from there. Anyone in my organization who wants to
circulate a document among an adhoc group of people, would drop it in
the shared database, with the group of folks listed on the document.
Then it would be visible to them as they replicate, but not to anyone
else. Once replicated to the collaborators client machines, they'd be
able to browse the data with the full power of map reduce. (They'd
also be able to strip the _acl and post the doc to slashdot...) It's
just that the shared database which implements reader access control
lists wouldn't have views.

Doing this is possible today but it involves a bunch of filtered
replication and app code to enforce that filters are applied.
Providing an optional shared or reader_acl mode for use at sync points
seems like a user friendly way to simplify something people already
want to do.

A potential design:

On the _security object setting reader_acl = true would enable the
reader access control lists, and make _views and _lists (and geocouch,
etc) into admin-only resources. I am not sure about _show and _update,
they should be safe to have, but it'd also be OK if we just made the
reader_acl databases super-simple just for replicating.

I'm imagining the way the reader ACLs would look on the documents is a
new top level field "_acl" that has a similar names/roles value
structure as the _security object:

{
_id : "someid",
foo : "bar",
_acl : {
   names : ["jchris@couchbase.com"]
   roles : ["aliens", "dogs"]
}

So this a document that can be read by me, and also by any aliens or dogs.

I am not proposing the alter the validate_doc_update system at all. So
any database with reader_acl = true would probably also want a
validate doc update function. The _acl field will of course appear in
there, so, for instance, you can easily write a validator that says
that documents may only be updated by their readers, by making
reference to the doc._acl field. Also, just like in _security, there
is no rule against saving extra junk like this:

{
_id : "someid",
foo : "bar",
_acl : {
   names : ["jchris@couchbase.com"]
   roles : ["aliens", "dogs"],
   weaknesses : ["cupcakes", "britcom"]
}

So maybe you want your validator to relax the rules and let anyone
save a document as long as it mentions cupcakes or britcom.

I'm not saying it's a good idea to stick junk in your _acl aside from
names and roles, I'm just saying I won't stop you.

How do people feel about this proposal?

Chris

-- 
Chris Anderson
http://jchrisa.net
http://couchbase.com