On Sun, Jan 3, 2010 at 3:21 PM, Sam Bisbee <sbis...@computervip.com> wrote: > On Sun, Jan 03, 2010 at 01:18:26PM -0800, Chris Anderson wrote: >> On Sun, Jan 3, 2010 at 1:10 PM, Nathan Stott <nrst...@gmail.com> wrote: >> > If a user can access a document via Futon, he can access via the CouchDB >> > API >> > if he knows what he's doing. The data is exposed one way or the other if >> > you store it in documents that users can access. There is no key-level >> > protection on a document that I am aware of. Correct me if I'm wrong, >> > someone. >> > >> >> There is key-level write protection. There is not key-level read >> protection, and there are no plans to add it. >> >> Per document read-control turns out to be extremely non-trivial (think >> about information leakage via reduce, etc) such that Lotus Notes never >> even got it right. > > Out of interest, is there some documentation available on the subject (maybe a > CouchDB or Lotus Notes dev's blog post)? Also, I assume that this leakage > would > only happen locally and isn't exposed to remote users? >
There might be some discussion in the ML archives. The leakage is to anyone accessing the views. Basically, if you have a doc, with a list of users who are allowed to read it, it's not very hard to enforce. If that doc is in a map view, you can also mark the view rows with the list of allowed readers, and filter at query time to only show valid rows. Also not that hard. However, if you have a reduce function (calculating, say, total account balance) the results can leak private data to other users. The best solution would be to run the reduce on the client (against the filtered map rows) but then you lose all the benefits of reduce. It's not that it's absolutely impossible to do this, it's just that it's hard to think of a way that doesn't cause lots of unanticipated security headaches for devs. There's an alternate line of thought: if the server enforces read access per documents, and doesn't offer views at all, then users can replicate their slice of the database locally and run views on their local CouchDB. I think this isn't much different (in terms of the use cases it can support) from encouraging a database-per-user model, where users have read access to their entire database. Db-per-user is much simpler, and we plan to support it. Chris > Thanks, > > -- > Sam Bisbee > -- Chris Anderson http://jchrisa.net http://couch.io
