Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of jason@jasondavies.com
 designates 89.145.97.179 as permitted sender)
Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes
Mime-Version: 1.0 (Apple Message framework v1076)
From: Jason Davies <jason@jasondavies.com>
In-Reply-To: <e282921e0909132212j21d7a779i8911bbc90b973ef4@mail.gmail.com>
Date: Mon, 14 Sep 2009 22:33:44 +0100
Content-Transfer-Encoding: 7bit
Message-Id: <B7C37FF1-39D7-4963-BEF1-2EB28FEF55AB@jasondavies.com>
References: <8F048321-4C3C-424C-8FC4-0C99354AB728@jasondavies.com>
 <8989606E-3CAF-42C9-9935-FCAC0FAD81D3@apache.org>
 <e282921e0909122307wa5921d1r903cd1f14c5330b4@mail.gmail.com>
 <EFDC5243-636E-4545-92C4-5C8A57DFE0E4@apache.org>
 <e282921e0909132212j21d7a779i8911bbc90b973ef4@mail.gmail.com>
To: dev@couchdb.apache.org
Subject: Re: Per-DB Auth Ideas and Proposal


On 14 Sep 2009, at 06:12, Chris Anderson wrote:

> On Sun, Sep 13, 2009 at 5:33 PM, Adam Kocoloski  
> <kocolosk@apache.org> wrote:
>>
>> Whatever name we choose, I think it should certainly be an
>> underscore-prefixed reserved name.  I'm partial to _acl myself.
>>
>
> works for me, but see my remarks about _filter below.
>
>>
>> If calling out to Spidermonkey on reads isn't as awful of a  
>> performance hit
>> as I expect it to be then supporting Vlad's validate_doc_read  
>> proposal would
>> also make sense from symmetry arguments.
>>
>
> I agree, I think validate-on-read is worth benchmarking.

Wouldn't the performance of validate_doc_read be equivalent to that of  
using _show?  You can roll your own validate_doc_read of sorts simply  
by writing a _show function using current trunk.  But yes, comparative  
benchmarks would be useful.  An informal benchmark on one of my sites  
reveals around 900 reqs/sec for accessing a naked doc and a paltry 60  
reqs/sec when using _show (-n1000 -c10).

> Especially in a replication context, the connection and process cost
> is roughly that of the _filter function. If we can encourage clients
> to use replication or bulk connections then a security filter will
> become especially viable.
>
> So even a simple benchmark of changes with and without _filter would
> be informative.
>
>>> I also thought about adding allow/deny so that eg, everyone but Joan
>>> could see Joan's surprise party invitation. But that seems to wreck
>>> havoc with any kind of sane way to make security work with views.
>>
>> Can you say a little more about this?  How are you envisioning view  
>> security
>> working with per-document controls?  It seems to me that once you  
>> have
>> per-doc ACLs view security is already complicated, and you might as  
>> well go
>> all the way to allow/deny support too.
>>
>
> With just a read control list you could enforce that views emit  
> something like:
>
> [{role: "player"}, play, description]
>
> and
>
> [{user:"coach"}, play, description]
>
> and then you could validate that certain view queries are allowed from
> user X. That is, you could make a rule that enforces that only user
> "coach" can read view rows where the first element is {user:"coach"}
>
> And similarly, to read rows with keys starting with {role, "player"}
> you'd have to have "player" in your roles list.
>
> It's expensive from a disk-space perspective but it works simply even
> for reductions.
>
> I can't see how this would work for deny, without making the disk
> usage astronomical.

I like this approach to solving security for views.  I think deny  
rules are possible but you have to do multiple range queries for this  
to work.  For example you could look up ?startkey={deny: null}&endkey= 
{deny:"jason"} and then ?startkey={deny:"jason"}&endkey={deny:{}} <--  
we need some way to perform a different range query here i.e. greater- 
than instead of greater-than-or-equal-to, I think there is a ticket  
for this somewhere?

I think we already need to do an extra query to support wildcards so  
adding another two wouldn't hurt.

>>> The other option is to require views be calculated on the client,
>>> which means you can punt on view security, and just let read- 
>>> security
>>> handle it during replication.
>>
>> Huh?
>>
>
> Heh - the easiest programming model for security is to forgo
> server-side views altogether, so that client interact with the server
> through replication.
>
> Then you could handle read security with a server-enforced _filter
> function during replication. You'd program security rules into the
> filter function, and it could eg: make sure players can only see
> playbooks for their own team, but that referees can see all playbooks.
>
> The client can replicate whatever they are allowed to see, and build
> any views they can think of, without compromising security. Not to
> mention all the computation saved on the server-side for building
> views for each user.
>
> (I'm well aware that a programming model like this presupposes a
> personal CouchDB capable of bidirectional replication and local view
> generation. But doesn't that sound relaxing?)
>
> With a _filter function based security model, implementing deny
> semantics (Joan's surprise party) gets a bit easier, too. If we can
> make it work from a concurrency perspective than I'd be all for it.
>
> Maybe we just need to require the _filter function be written in
> Erlang. Oh and that clients generate their own views. ;)


Sounds good but if the performance is akin to running _list over all  
the docs it could be quite slow for a gazillion docs, or am I missing  
something?

Thanks,
--
Jason Davies

www.jasondavies.com