couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: Introducing Bram Neijt
Date Tue, 26 Oct 2010 14:48:06 GMT
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:

(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.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!


View raw message