couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Introducing Bram Neijt
Date Tue, 26 Oct 2010 15:25:30 GMT
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.

Adam


Mime
View raw message