On Sat, Aug 27, 2011 at 2:39 PM, Chris Anderson <[email protected]> wrote: > 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 : ["[email protected]"] > 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 : ["[email protected]"] > 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 >
I'm still thinking this through, but the most glaring issue that comes to mind: What about conflicts?
