couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jason Smith <...@iriscouch.com>
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
<geddes.jonathan@gmail.com> 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
validate_doc_update().

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

Mime
View raw message