couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: Per Document Filtering/Authorization
Date Fri, 03 Dec 2010 04:42:06 GMT
A separate database is a bad idea IMHO. Whatever solution to
per-document filtering we come up with should allow for the
CouchApp-style database-as-application paradigm where one expects to
get a fully working application by replicating a single db.

On Thu, Dec 2, 2010 at 23:16, David Pratt <fairwinds.dp@gmail.com> wrote:
> Hi Chad. Yeah, reason for _type was that it fits with what most folks
> are doing already - no changes. Putting security in a separate
> _authorization database isolates it so there is no additional overhead
> for those that do not wish to implement it (again, no changes).
> Second, being a special database, no MCVV overhead and potential to
> load into a cache (since it is small) and lookups ought to be fast and
> inexpensive. ACLs are also pervasive, simple and easily understood.
> Lastly, it also integrates with Names and Roles that we are already
> using with inherent permissions associated by Admin and Readers
> groups. In my previous note I showed how easy it would be to isolate a
> type to a user or role (where one or more entries can effectively
> limit or isolate access).
>
> Personally, I think a separate function per doc adds substantial
> overhead. Each doc is susceptible to versioning. The overhead of a
> single key per document _type in an _authorization database is much
> less by an order of magnitude since the number of types is small
> comparatively to documents. As a result, an _authorization database
> would be quite small - even in relation to the _users database. I am
> thinking that it ought to be possible to implement with minimal logic
> as well.
>
> On the issue of overhead, consider the difference between a database
> containing 10 million versioned docs - each having a security method
> compared to an _authorization database having a fast lookup of types
> that checks access control entries. I would be surprised that an
> _authorization database would contain any more than 100 records (where
> each doc corresponds to a  _type. Each type only needs to possess a
> single _acl attribute containing a list of perhaps one to three items
> to evaluate. Being so small, caching for lookups seems a reasonable
> way to get speed. The notion of caching fits well with the scale we
> want from a large sharded data stores.
>
> I could see a need to consider a naming strategy in _authorization
> that could provide isolation of acls on a per database basis. This
> would not make things any more complicated as the database we are
> working with is already part of the context. Editing an acl would be
> no different for the fact you would be concerned with a record for a
> specific database.
>
> Anyway, is good to talk about ideas since this is ultimately the only
> way anything may be eventually realized.
>
> Regards,
> David
>
>
> On Thu, Dec 2, 2010 at 6:43 PM, Chad George <chad@mgproducts.com> wrote:
>> One important use case where a validation function works better is when the
>> same document "type" needs to be only accessible by certain users (like the
>> document's creator).
>>
>> I'm not certain what we gain by having a separate _authorization database
>> over just putting that information in a design document.
>>
>> Your document "_type" field is conceptually similar to my original idea of
>> attaching the access validator to a document to give it a type. A more
>> generic type field that could be used for view filter is probably better
>> though and might relieve previous objections to directly assigning security
>> functions on the data.
>>
>> Perhaps we could combine both ideas:
>>  - add an official "_type" field to the document API since its pretty common
>> anyway.
>>  - design documents have a _access field which is a dictionary associating
>> _types for that database with either a whitelist/blacklist ACL or a function
>> that is evaluated with the request context and document.
>>
>> - Chad
>>
>> On Thu, Dec 2, 2010 at 12:14 PM, David Pratt <fairwinds.dp@gmail.com> wrote:
>>
>>> > which is already something most folks do for filtering views etc. If
>>> > there is no entry in _authorization database, the data accessible to
>>> > the extent that we have any Readers for database as it is now.
>>>
>>> sorry typo - last bit should have read ..
>>>
>>> the data would be accessible to the extent that we have any Readers
>>> for database as it is now.
>>>
>>> To add to above, it might be good for the system to have a special
>>> entity named "ALL" where access to everyone is not implied by the
>>> absence of record in _authorization for the _type but could be made
>>> explicitly if desired.
>>>
>>
>

Mime
View raw message