incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: no 'writers' section in _security killing me
Date Tue, 19 Jul 2011 20:11:30 GMT
2011/7/19 Javier Rodríguez Escolar <javiescolar@gmail.com>:
> 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 <jhs@iriscouch.com>
>
>> 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