Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of robert.newson@gmail.com
 designates 209.85.210.180 as permitted sender)
MIME-Version: 1.0
In-Reply-To: 
 <CAAL6JQi1DBTZM-1A6_Bw8hWKuu6fRnRK9YGSCEyieC3oBvu8fA@mail.gmail.com>
References: 
 <CAFnw-00a2hux2T0ZP=wKGHq++je4AmXTjZQxKWTXpvezOtvZeg@mail.gmail.com>
	<CAN-3CBLAY1-UzbRsaR_aaJNT+uh8pPjOT_WoL83ex13wvU-Q4w@mail.gmail.com>
	<CAFnw-03MZdTm1fOcjGepZQCLq5yLiDooKr92SR2frg9nf1YJYQ@mail.gmail.com>
	<CAN-3CBLGPYC+zJSVzUUEVTn7XDSrm6Ce2yUTJkUqDBy3JtkKpQ@mail.gmail.com>
	<CAL8PC1+aynmGFHB0JnFwQp3ZMmt3BbjHv2X8x=OcB9T3kqEbmQ@mail.gmail.com>
	<CAAL6JQi1DBTZM-1A6_Bw8hWKuu6fRnRK9YGSCEyieC3oBvu8fA@mail.gmail.com>
Date: Tue, 19 Jul 2011 21:23:50 +0100
Message-ID: 
 <CABvT1DF9SPKftpDA0j4=31WgjppL_UWGq_U2jGTr0oC6iLTNGw@mail.gmail.com>
Subject: Re: no 'writers' section in _security killing me
From: Robert Newson <robert.newson@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable

there is a wiki page for this with only one reasonable solution (db per use=
r).

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 <randall.leeds@gmail.com> wrote:
> 2011/7/19 Javier Rodr=EDguez Escolar <javiescolar@gmail.com>:
>> Hello,
>>
>> I have been reading for a while about the existing possibilities to rest=
rict
>> the read access to a database in which different users write. I mean, al=
l
>> users should be able to write, but they should only read what they have
>> written. =A0As far as I can read a common workaround to carry out this i=
ssue
>> is to create a =932.1 layer architecture=94 as follows:
>>
>> =A0 - There is a database per user. The user's name will be added to the
>> =A0 _security object.
>> =A0 - There is a private master database. The admin=92s name will be add=
ed to
>> =A0 the _security object.
>> =A0 - There is a public database.
>> =A0 - There is an external server in charge of copying the data from the
>> =A0 public database to the private one.
>>
>>
>> A very common way to proceed is to let the users write in a public datab=
ase
>> 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 fro=
m
>> the public database. To my mind, this approach doesn=92t seem to be very
>> secure since any other external server might be monitoring the changes i=
n
>> the public database so the security of critical data might be compromise=
d.
>> Wouldn=92t be better to have a middle layer when managing critical data?=
 I=92m
>> newbie to Couchdb so I=92m 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 documentati=
on
>>> 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 li=
mit
>>> >
>>> > (/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 vie=
ws
>>> 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 crashe=
s
>>> >> 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
>>>
>>
>