couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Vlad GURDIGA <gurd...@gmail.com>
Subject Re: Per-DB Auth Ideas and Proposal
Date Tue, 15 Sep 2009 05:55:32 GMT
On Sun, Sep 13, 2009 at 8:44 PM, Chris Anderson <jchris@apache.org> wrote:
> On Sun, Sep 13, 2009 at 12:48 AM, Vlad GURDIGA <gurdiga@gmail.com> wrote:
>> I'm sorry to break the wave, but I wonder would it be practical to
>> have a kind of validate_doc_read.js? It would give a certain level of
>> consistency with the validate_doc_update.js mechanism, and we would
>> probably be able to have a unified security meta-data looking like:
>>
>> var role = {
>>  editor: {
>>    can: {
>>      read: {books: true, authors: true},
>>      write: {books: true, authors: true},
>>      add: {books: true, authors: true}
>>    }
>>  }
>> };
>>
>> var user = {
>>
>>  john: {
>>    can: {
>>      read: {books: true, authors: true},
>>      add: {books: true, authors: true}
>>    },
>>    has: {
>>      role: {editor: true, administrator: true}
>>    }
>>  },
>>
>>  mary: {
>>    can: {
>>      read: {authors: true},
>>      add: {authors: true}
>>    },
>>    has: {
>>      role: {editor: true}
>>    }
>>  }
>>
>> };
>>
>> This maybe looks a little verbose to write but feels pretty readable:
>>
>> if (!user[userCtx.name].can.read.books && !user[userCtx.name].has.role.editor)
{
>>  throw "Read access denied";
>> }
>>
>> It would decouple security meta-data from the data itself (I'm not
>> saying that this would necessarily be a good thing though, let's
>> discuss).
>>
>> What do you think?
>>
>
> I think this is a cleaner and more flexible model. It would be slow as
> hell though, as you'd have to do all that serialization on every read,
> not just on updates.
>
> I wonder how slow it would be. I'm guessing it'd take CouchDB from
> thousands of reads per second to tens of reads per second, but that's
> just a guess.

Yeah, calling out to Spidermonkey on reads looks way too expensive.
I'm thinking... would it be possible to parse and suck the ACL
meta-data in the Erlang runtime (as it happens with the local.ini
configuration file for example) to avoid the performance penalty?

> It also doesn't take into account view read permissions.

Maybe we could come extend the ACL with rules for views (and DB?)?
Something like:

  mary: {
    can: {
      ...
      acces_view: {view_name: true}
    }
  }



> Maybe it is better to think about doc ACL later, and just concentrate
> on per-db auth for now.
>
> Chris
>
> --
> Chris Anderson
> http://jchrisa.net
> http://couch.io
>

Mime
View raw message