incubator-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 Wed, 28 Sep 2011 12:23:07 GMT
A while back, Chris Anderson mentioned an idea for an "inbox database":

* CouchDB allows non-members (non-readers) to write to the database.
* The validate_doc_update() functions still approve all changes, of course

I wrote an implementation and submitted the patches to JIRA. I am
hopeful it can be pulled into the 1.3 release.

On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <> wrote:
> there is a wiki page for this with only one reasonable solution (db per user).
> The trick is solve read access for reduce views without violating
> common sense notions of read security. Everything else is easy by
> comparison.
> B.
> On 19 July 2011 21:11, Randall Leeds <> wrote:
>> 2011/7/19 Javier Rodríguez Escolar <>:
>>> Hello,
>>> I have been reading for a while about the existing possibilities to restrict
>>> the read access to a database in which different users write. I mean, all
>>> users should be able to write, but they should only read what they have
>>> written.  As far as I can read a common workaround to carry out this issue
>>> is to create a “2.1 layer architecture” as follows:
>>>   - There is a database per user. The user's name will be added to the
>>>   _security object.
>>>   - There is a private master database. The admin’s name will be added to
>>>   the _security object.
>>>   - There is a public database.
>>>   - There is an external server in charge of copying the data from the
>>>   public database to the private one.
>>> A very common way to proceed is to let the users write in a public database
>>> and use an external server (NodeJS) to listen for changes on the public
>>> database, move the data to the private master database and remove it from
>>> the public database. To my mind, this approach doesn’t seem to be very
>>> secure since any other external server might be monitoring the changes in
>>> the public database so the security of critical data might be compromised.
>>> Wouldn’t be better to have a middle layer when managing critical data? I’m
>>> newbie to Couchdb so I’m probably missing something.
>> Yes. A middle layer is the way to go if you really want to get data
>> straight into a private database.
>> Thanks everyone for suffering through these workarounds.
>> The community has been discussing more access control features for a
>> long time. It's a delicate balance of trying to fulfill everyone's
>> needs (or at least 80% of them), not destroying performance in the
>> process of adding more controls, and keeping the API simple and
>> elegant. I think the mailing list is no longer the place to discuss
>> these things because conversations go for a while, stall, and then
>> resurface with the same issues re-hashed. Perhaps a wiki page about it
>> could serve as a working, evolving draft?
>> -R
>>> Thanks and best regards,
>>> Javi
>>> 2011/7/11 Jason Smith <>
>>>> 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
>>>> 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
>>>> 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

Iris Couch

View raw message