On Tue, Aug 30, 2011 at 6:48 AM, Chris Anderson <[email protected]> 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
