couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Newson <rnew...@apache.org>
Subject Re: Enforced filter functions
Date Tue, 13 Mar 2012 21:32:09 GMT
Summarizing some things I said on IRC:

I'm more than a little nervous about any more steps that appear to
give fine-grained read access control within a database. We have
repeatedly rejected the idea when it's been raised by community
members citing the numerous problems that come with it (data leaking
via views, for example) so we risk introducing even more confusion
with a volte face. If we pursue this, we must get it right.

Today there's at least one case where we currently have mandatory code
execution, validate_doc_update, that is causing issues. Because it
cannot be bypassed, even by an admin, BigCouch, which strives to make
N copies of every document, can be hindered. This example illustrates
some part of the danger that 'enforced' code execution brings. Dale
does state that the proposed filters would affect non-admins but we
should be be conscious of how different couchdb looks and behaves to
users vs admins.

I agree completely that we need to add features incrementally rather
than attempt some giant feat within a release. What I haven't yet
heard is a coherent plan for where we'll end up. As a committer, I
share responsibility in helping to define and deliver that plan.

B.


On 13 March 2012 15:33, Dale Harvey <dale@arandomurl.com> wrote:
> On 13 March 2012 15:30, Dale Harvey <dale@arandomurl.com> wrote:
>
>> So I was trying to implement the ability for logged in users to subscribe
>> to the changes feed for updates to their own documents (its currently admin
>> only), its a simple patch but its not very clean (mostly because the we
>> dont want to have the changes feed read the full document)
>>
>> A way that I could implement it, that seems a lot more globally applicable
>> and applies cleaner, is to allow the ddoc author to enforce filters to
>> happen on non admin access to _changes and replication (on any database)
>>
>> This should negatively affect anything else, filters are already used and
>> supported in both places, I have also seen it asked for regularly in the
>> context of replication, ddoc authors could specify exactly what users are
>> allowed to replicate, the enforced filter would override any users filter
>>
>>
> Obviously I meant "should not negatively affect" :)
>
>
>> As far as I can tell the only problem would be how to have the author
>> specify the enforcement, apart from that it should apply cleanly,
>> introduces a fairly large amount of new functionality and adds very little
>> overhead
>>
>> Ideas?
>>
>> Jan mentioned this could be used more widely for updates / shows / lists,
>> that is starting to sound more complicated and does start introducing
>> problems, I would prefer to look at the simple case of filters for changes
>> / replication for now, but if there was an even more global solution that
>> applied cleanly, I would be happy to
>>
>>
>>

Mime
View raw message