Re: Introducing Bram Neijt

[Jan Lehnardt <ja...@apache.org>]

On 26 Oct 2010, at 17:25, 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.

http://s.apache.org/couchdb-per-doc-auth

Cheers
Jan
-- 

Re: Introducing Bram Neijt

[Bram Neijt <bn...@gmail.com>]

Dear all,

Here is a quick status update on the per-document authentication work.

I've done some combining of knowledge and had some thoughts, I've put them on
http://wiki.apache.org/couchdb/PerDocumentAuthorization

I've decided that all this thinking has been more then enough, and
I've started to look at implementing security for the Pages[1]
couchapp.

Soon I hope to finish strengthening the validate_doc_update.js
function and start to work on making the _user database less readable
for the normal user. Any thoughts on that, feel free to mail me.

Greets,

Bram

[1] https://github.com/couchone/pages

On Mon, Nov 8, 2010 at 5:08 PM, Jan Lehnardt <ja...@apache.org> wrote:
>
> On 26 Oct 2010, at 17:25, 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.
>
> http://s.apache.org/couchdb-per-doc-auth
>
> Cheers
> Jan
> --
>
>
>