couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Young <benja...@couchone.com>
Subject Re: Introducing Bram Neijt
Date Tue, 26 Oct 2010 15:39:35 GMT
On 10/26/2010 11:25 AM, Adam Kocoloski wrote:
> On Oct 26, 2010, at 10:48 AM, Jan Lehnardt wrote:
>
>> Hi Bram,
>>
>> On 26 Oct 2010, at 11:51, Bram Neijt wrote:
>>
>>> I'm a developer at Xebia and I've been granted about 5 hours a week to
>>> spend on implementing any open source project problem I would like to
>>> see fixed.
>> This major awesome! :)
>>
>>
>>> I've chosen to have a go at per document authorization for couchdb.
>> Uh-oh :) — See below.
>>
>>
>>> As I'm weeding through the archives, I would love to hear about the
>>> current approaches, who is involved, what is planned and what may be
>>> considered an acceptable solution.
>> To get started more generally, it might make sense to check out
>> our list of issues sorted by how hard they are to solve:
>>
>>   http://s.apache.org/couchdb-easy-issues
>>   http://s.apache.org/couchdb-medium-issues
>>   http://s.apache.org/couchdb-hard-issues
>>
>> (Thanks again for Paul Davis to produce these lists)
>>
>> --
>>
>> As for per-doc auth: It is very hard to get right and probably
>> against the nature of CouchDB. I'm not saying we shouldn't try
>> to solve it, but we need to be aware of the impact.
>>
>> I remember Damien saying that Notes did get per-doc auth, but
>> it wasn't a good solution and it sucked ever since. I don't
>> think anybody here wants that :)
>>
>> The biggest problem here are views, the reduced kind.
>>
>>  From the reduce value, CouchDB can't deduce what documents were
>> used to create the value.
>>
>> Imagine three docs
>>
>> {"name": "a", "amount": 3}
>> {"name": "b", "amount": 5}
>> {"name": "c", "amount": 7}
>>
>> A map function:
>>
>> function(doc) {
>>   emit(doc.name, doc.amount);
>> }
>>
>> A reduce function:
>>
>> function(keys, values) {
>>   return sum(values);
>> }
>>
>> Now the reduced result for this view is 15. Now say you don't
>> have access to read the document with `"name": "b"`. Should you
>> be able to access the view? If yes, what result should you see?
>> 15? 10?
>>
>> If you get 15, then the view is leaking information that you
>> are not supposed to see (IIRC that's how Notes works).
>>
>> If you are supposed to get 10, the underlying data structure
>> would have to compute a view for each user based on his/her
>> authorization settings. And invalidate the view every time
>> these are changed.
>>
>> To make a rather straightforward implementation of that, J Chris
>> proposed the idea of prefixing views with the username and only
>> allowing reads with a prefix that is the authenticated username.
>>
>> While that is conceptually rather easy, you are basically creating
>> a view for each user. This may work for small amounts of data,
>> but not large, and many users.
>>
>>
>> Again, I'm not saying, you shouldn't attempt to solve this,
>> because that'd be über-rad, but there be dragons :)
>>
>> Either way, you may want to jump in with the easier open issues
>> to get a feeling for the codebase and the procedure of submitting
>> patches and all that.
>>
>> Glad to have you on board!
>>
>> Cheers
>> Jan
>> -- 
> Well said Jan, and welcome Bram!  This explanation needs to not get lost in the archives.
+1 for getting this on the wiki, a blog, or somewhere that it's 
findable. It's sort of become "lore" that per-document permissions 
aren't currently doable in CouchDB, but this is the clearest explanation 
I've heard, and worth repeating in a more public venue. :)

Thanks, Jan,
Benjamin
> Adam
>


Mime
View raw message