On 14 Sep 2009, at 06:12, Chris Anderson wrote:
On Sun, Sep 13, 2009 at 5:33 PM, Adam Kocoloski
<[email protected]> 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
