Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jchris@gmail.com designates
 209.85.216.180 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=cQ0Bv1lArZ8fY5GZQrGy313/XPB30OQ/kpgvWFnZ4jcT0rIBmBfgMT6bGF07kNCuh9
         eslfG+QdACXzNWOF42SzbWrrim3NY+hfkSXIObxYDrgDqJhnKPKWw08Pyc2nHLNQ2+cy
         oyLBd2Z3QIOFl5SX7TK1aowKAQ92kPvzENYJc=
MIME-Version: 1.0
Sender: jchris@gmail.com
In-Reply-To: <20100103232151.GD5653@orbital>
References: <6adfa88d1001030531r6f853f2cu7d68c7b7e242b7bc@mail.gmail.com>
	 <-2906993493094027579@unknownmsgid>
	 <098DCF08-B9FD-4380-A1F6-38F337A0795D@gmail.com>
	 <e282921e1001031113h63e07de1mc0b4a34b613d415c@mail.gmail.com>
	 <DD4EE67C-8037-4A65-8108-1DF7420BFCE2@gmail.com>
	 <e282921e1001031140j2df37689vff700422298c6f82@mail.gmail.com>
	 <20100103200710.GB5653@orbital>
	 <ea28b75b1001031310q5af89d45j8f0b5639ae4e2d4e@mail.gmail.com>
	 <e282921e1001031318jb57a51cr72e0686e3e2ba3ea@mail.gmail.com>
	 <20100103232151.GD5653@orbital>
Date: Sun, 3 Jan 2010 16:12:33 -0800
Message-ID: <e282921e1001031612t352dade1y40364f2bfe7a23e2@mail.gmail.com>
Subject: Re: Common security pattern?
From: Chris Anderson <jchris@apache.org>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 Couch=
DB API
>> > if he knows what he's doing. =A0The data is exposed one way or the oth=
er if
>> > you store it in documents that users can access. =A0There is no key-le=
vel
>> > protection on a document that I am aware of. =A0Correct me if I'm wron=
g,
>> > 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 (ma=
ybe 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
>


--=20
Chris Anderson
http://jchrisa.net
http://couch.io