couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Candler <>
Subject Re: Reader ACLs
Date Tue, 19 Jan 2010 06:40:45 GMT
> The nice thing about the current comparisons is that they are made
> in-memory, with no db access necessary to perform them.

I was imagining that this sort of thing would be cached the first time that
you touch a particular database.  But I can see that involves work, because
of the stateless nature of couchdb.  After all, we're not a SQL database
with a client connection :-)

> Documents are great for application level functionality. But when we
> are talking about db-prefs (admins and readers) it makes things more
> predictable that they don't replicate.

If it's desirable that these things *don't* replicate, then I propose the
following instead.

(1) User has a role "dbname:_admin" if they're a database administrator, and
"dbname:_reader" if they're a reader.

(2) That's it.

I make the following observations:

* We already must know the roles associated with this user, so
  the checking is cheap
* It scales (N users each with access to M databases)
* It doesn't have concurrency issues
* It doesn't involve a special API nor changes to the on-disk format
* It easily supports the idea of a separate "db:_manager" role (who can
  add and remove users to a database, except for _admins)

Now, we want world-readable databases too. I suggest the simplest thing
there is to have a user whose name is "_anon", and every time you create a
database you add it as a reader on that user (unless you ask for a private
database). A user who is not logged in gets the roles of _anon instead.

There is one huge advantage here. When a user queries _all_dbs you can
immediately return only the list of databases that they have access to (just
from their user record plus the _anon user record).  Even if you have a
million databases, but this user has only access to 20 of them, you can show
those 20 without having to do a full disk scan.  (The system-level _admin
user would do the normal database scan still)

> Again, the only way to scale this design to large #s of user accounts,
> is to keep the user accounts in the per-server users db

Then let's use a scalable way from the start.



View raw message