couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <paul.joseph.da...@gmail.com>
Subject Re: Proposal: Reader Access Control Lists
Date Tue, 30 Aug 2011 01:25:43 GMT
On Sat, Aug 27, 2011 at 2:39 PM, Chris Anderson <jchris@apache.org> 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 : ["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
>

I'm still thinking this through, but the most glaring issue that comes to mind:

What about conflicts?

Mime
View raw message