couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <>
Subject Re: Proposal: Reader Access Control Lists
Date Fri, 02 Sep 2011 16:13:31 GMT

I still think about your solution. Long time ago I also proposed an
acl solution, where the design was simpler, that worth a read I think

Anyway some questions that come to mind with such system:

- how does it survive to the replication? How to make sure benoitc is benoitc?
- how do you make sure acl doesn't change while you edit the file
(conflicts and such?)
- performances: usung such textual system will kill any performances
under load. I would be in favour of a mask system or maybe content id
& signature system. If I remember well this is the path that choosed

What I like in acl / db anyway is that you only check once. Then go.
Then you can imagine group of users etc.
Also other thing that I like in current system, is that you don't rely
on a local base of user once it's replicated.

- benoit

On Sat, Aug 27, 2011 at 9:39 PM, Chris Anderson <> 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 : [""]
>   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 : [""]
>   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

View raw message