couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <>
Subject Re: no 'writers' section in _security killing me
Date Mon, 11 Jul 2011 07:17:03 GMT
On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
<> wrote:
>> Fortunately, users with write access are not admins. They may not
>> modify design documents. All of their changes are subject to design
>> documents' validate_doc_update() function.
> I would be *overjoyed* to hear that you are right and the documentation at
> [0] is wrong:
>> database admins - Defined per database. They have all the privileges
> readers have plus the privileges: write (and edit) design documents,
> add/remove database admins and readers, set the database revisions limit >
> (/somedb/_revs_limit API) and execute temporary views against the database
> (/somedb/_temp_view API). They can not create a database and neither delete
> a database.

D'oh, Marcello posted a pithy and timely answer while I had lunch.
I'll send anyway.

The typical setup is:

* 1 server admin
* 0 or more database admins (name or roles in _security.admins)
* An admin deploys a design document
* Several normal users (name or roles in _security.readers but *not* admins)

"readers" is a misnomer. It really means "members." Read access is
database-wide, write access is at the pleasure of

To that end, Chris changed CouchDB so that future releases will use
the "members" field. He committed his change last Thanksgiving
weekend. Thanks, Chris!

> I'm gonna set up a little experiment in the morning (when I can think
> clearly) to find out for myself. The _revs_limit PI and temporary views are
> scary too.

I strongly encourage an experiment. 15 or 20 minutes of poking around
will make things very clear.

Cloudant has a brilliant UI to impose more intuitive and traditional
security policies for exactly this reason.

>> I call it a 2.5-layer architecture
>> because there is no middleware, but it still requires a third
>> component, to watch over things. The drop box would be amazing;
>> however I am still happy with my architecture because bugs or crashes
>> in the third component are not so devastating to the user experience.
> The great thing about this architecture is that you can easily have CouchDB
> monitor the third party stuff and keep it running with external OS processes
> [1]. I like the term '2.5-layer' :D.

Is it too late to change the name to "2.1-layer"?

* Hints that the extra step is not going to break your back
* Kind of like 5.1 surround sound

> By the way, why hasn't this been implimented before? It seems strange to me.
> Is there something inherent in the architecture of CouchDB that makes this
> difficult?

I think it is a matter of time. The people in a position to implement
it have not felt quite enough pressure.

/me whistles innocently.

Iris Couch

View raw message