couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bram Neijt <bne...@gmail.com>
Subject Re: Read access control
Date Mon, 27 Dec 2010 16:00:43 GMT
Hi Svien,

I've set up a wiki page describing a few possible protection scenarios[1].

Currently the most common is to create a database per user (using a
helper script to sync the database names/access and the a _users
table). After doing that, a user can set up their private documents in
their private database, and have public documents in a public
database.

The current authorization modules combined with read access for the
different databases will help you set up enough security. One still
has to protect the _users database to make sure that users are not
allowed to copy the password hash of other users, but I have no idea
how to handle that yet.

Currently per document authorization is not a focus of the couchdb
project and although I have written a patch, I doubt it will ever hit
the mainstream system because of the performance hit. The "Database
per user" approach is currently your best approach if you want to have
couchdb connected to the internet directly, otherwise you will have to
proxy it in some way.

Greets,

Bram

[1] http://wiki.apache.org/couchdb/PerDocumentAuthorization


On Sun, Dec 26, 2010 at 4:37 AM, Svein Helge Grinden
<svein.helge.grinden@gmail.com> wrote:
> Hi
>
> I have seen several discussion around read access pr document. One of the
> bigger issues I have seen being discussed  is how to handle reduce
> functions. Other issues would be replication and performance.
>
> Have it been discussed the possibility to enforce view and parameters?
>
> Let's say we had a setting called for example only allow read using view.
> This setting would block any form of read access except when using a view.
>
> Then we could inside a view enforce different parameters and
> throw exceptions on illegal or missing parameters.
>
> Today we have validate_doc_update, so if we added validate_doc_read, we
> could use the validate_doc_read to validate call to the view.
>
> Example:
> We have a set of documents with a field called customernumber.
> We have a user with field called customernumbers (for example: 1, 2, 3)
>
> When the view is called it would call the validate_doc_read function. Inside
> this function we could add for example add this: doc.customernumber == 1
> || doc.customernumber == 2 || doc.customernumber == 3 (this would be done
> through a loop getting  values from the users customernumbers). This way we
> enforce the query to only query for documents with customernumber equal to
> one of user's customer numbers.
>
> This way the view will work as it does today, except that more filters is
> added by the validate_doc_read function. Reduce functions will work as they
> do today. Replication would not be affected. Caching may be affected and
> some performance impact off course but adding more security without any form
> of performance impact is almost impossible.
> To get even more security you could inside the validate_doc_read function
> add a check for allowed_views (field added to user). If the user do not have
> the accessed view in his allowed_views array we would throw an exception.
>
> By doing this we would get read access control pr document. Off course this
> would not cover all security scenarios but I think this would cover enough
> since CouchDB are not meant to solve every possible database scenario.
>
> What are your thoughts?
>

Mime
View raw message