couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
Subject Re: Proposal: Reader Access Control Lists
Date Tue, 30 Aug 2011 01:55:43 GMT
On Tue, Aug 30, 2011 at 6:48 AM, Chris Anderson <jchris@apache.org> wrote:
>>> Doing this is possible today but it involves a bunch of filtered
>>> replication and app code to enforce that filters are applied.
>>
>> This is a very important statement. I take you to mean there are
>> multiple solutions to this problem; and by implication ACLs are the
>> best solution.
>
> You can do this with behind-the-firewall filtered replication and
> database per user. With reader access control lists you'll be able to
> do it all from a single database syncpoint. (It's just that database
> won't have views enabled, so anyone who wants to browse it will want
> to browse a replica.)

How do you feel about ACL databases vs. a hypothetical support system
built into couch where it manages per-user DBs and continuous filtered
replication and all the rest of it?

Both strike me as, ballpark, the same amount of work.

>>> 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:
>>
>> A note about CouchDB adoption and comprehensibility: usually ACLs
>> (especially role-based systems like Couch) are not simply one list of
>> readers; but a matrix with rights as columns and roles as rows; and
>> you have yes/no values for roles/rights combinations.
>>
>> Perhaps a bit more structure, then:
>>
>>    { "_id": "someid"
>>    , "_acl":
>>      { "read": {"names": [...], "roles": [...]}
>>      , "write": {"names": [...], "roles": [...]}
>>      , "can_update_on_tuesdays": {"names"..., "roles"...}
>>      }
>>    }
>>
>> validate_doc_update could still implement the "write" and
>> Tuesday-updates support, but I propose you give them a namespace to
>> work with.
>
> you can always stick extra junk in there. So what you describe would
> really just be us making the API look like this:

Maybe it's a subtle difference, but what you describe is *not* an
access control list by the common definition. I propose a minor change
to fit the principle of least surprise. If it's an access control
list, you usually say what the access is, and who is on the list.
_security is an ACL. _security.readers is an L.

> If we think we may want doc._acl.write someday, we are better off
> leaving space for it now, with your schema instead of mine. But I am
> not sure if we will want those. I want to hear from more people on
> this. To me it smells complicated, so I wanna stay away from it for
> now.

I see a broader problem with couch app security. Many people run Couch
in production with no validators, some even still in Admin Party!

If ACL DBs existed, I predict people would enthusiastically fill out
the forms and feel confident.

I would definitely submit patches for built-in "write" (doc changes
but no _acl changes) and "change_acl" (_acl changes) support. Maybe
even "allowed_fields", who knows? (An initial implementation could
check for ACLs in _security and just drop in a _design/acl doc with a
validator.)

-- 
Iris Couch

Mime
View raw message