incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Common security pattern?
Date Mon, 04 Jan 2010 00:12:33 GMT
On Sun, Jan 3, 2010 at 3:21 PM, Sam Bisbee <sbisbee@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 <nrstott@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

Mime
View raw message