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: local policy)
Message-ID: <4AAE9F36.50000@canonical.com>
Date: Mon, 14 Sep 2009 15:53:26 -0400
From: eric casteleijn <eric.casteleijn@canonical.com>
User-Agent: Thunderbird 2.0.0.23 (X11/20090817)
MIME-Version: 1.0
To: dev@couchdb.apache.org
Subject: Re: Per-DB Auth Ideas and Proposal
References: <8F048321-4C3C-424C-8FC4-0C99354AB728@jasondavies.com>
	 <8989606E-3CAF-42C9-9935-FCAC0FAD81D3@apache.org>
 <e282921e0909122307wa5921d1r903cd1f14c5330b4@mail.gmail.com>
In-Reply-To: <e282921e0909122307wa5921d1r903cd1f14c5330b4@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

> I played around with read & write access lists but write can be
> handled by the validation function so it's not necessary. 

I'm not entirely convinced the current validation functions, living in 
more or less as content in the database are sufficient for anything but 
very simple permission models.

I foresee a lot of problems if two users have very broad permissions 
(say what is currently known as 'admin') in the same database, but one 
shouldn't be able to modify certain design documents. Any way of 
modelling that with validation functions seems very tricky to me:

User 1, whom we shall call 'super_admin', creates a design document, 
with a validator function restricting all write access to any document 
with id prefix '_design/special_view_' to user 'super_admin'. The 
validator function itself should not be modifiable by user 2 
'regular_admin' or it is worthless, of course. This would work, except 
there is nothing stopping 'regular_admin' from adding their own 
validator, restricting 'super_admin' similarly from those 
design_documents, and from the design_document this validator is in, and 
now everybody is locked out.

Currently, I see no other possibility to model this (very real) use 
case, where you  want a user to be able to write to almost every 
document (by replication from their machine), except for a few views 
(because we'll be executing those on our cloud server node) without 
ending up with a variant on the above cold war arms race scenario.

The simplest way to solve this that I see is if the permissions live in 
a place that regular_admin simply does not have any access to (i.e. the 
global _user db) but where a global admin can grant or restrict 
permissions at will.


-- 
- eric casteleijn
https://launchpad.net/~thisfred
http://www.canonical.com