couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Introducing Bram Neijt
Date Tue, 26 Oct 2010 22:12:56 GMT
Thanks Dave, much appreciated.

If anybody else wants to beat him to it…it’s a public wiki :)

Cheers
Jan
-- 

On 26 Oct 2010, at 21:56, Dave Cottlehuber wrote:

> re wiki -> I will add this in next few days.
> 
> On 27 October 2010 04:39, Benjamin Young <benjamin@couchone.com> wrote:
>> 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