couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <>
Subject Re: Per-DB Auth Ideas and Proposal
Date Mon, 14 Sep 2009 05:12:40 GMT
On Sun, Sep 13, 2009 at 5:33 PM, Adam Kocoloski <> 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.

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]


[{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.

>> 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. ;)


Chris Anderson

View raw message