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 <[email protected]> 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 > -- > > >
