Re: no 'writers' section in _security killing me

[Jason Smith <jh...@iriscouch.com>]

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.

    https://issues.apache.org/jira/browse/COUCHDB-1287

On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>
>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>> <ge...@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
>>>>
>>>
>>
>



-- 
Iris Couch

Re: no 'writers' section in _security killing me

[Ryan Ramage <ry...@gmail.com>]

I think the pattern that Jens is following would be 2 databases still,
both normal couchdbs. The 'inbox' would have the public key as an
attachment, and allow all who post messages to encrypt with that key.
Then all messages docs would be replicated to the users db. This db
would have private access, so if a private key needs to be stored
safely, it can....thats how I would imagine it anyway.

I still thing the inbox db style that Jason is working on has a lot of
value though.

On Wed, Sep 28, 2011 at 9:59 AM, Zachary Zolton
<za...@gmail.com> wrote:
> For the validation function to decrypt the docs, I'm guessing the
> private key would have to be in the ddoc. Wouldn't users be able to
> read that and thus decrypt everything?
>
> (Sorry, I've been stalking this thread.)
>
>
> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>> This would be a great feature; I'd love to see it get in.
>>
>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>>
>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>>
>> --Jens
>>
>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>
>>> 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.
>>>
>>>    https://issues.apache.org/jira/browse/COUCHDB-1287
>>>
>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>>>>
>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>> <ge...@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
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Iris Couch
>>
>

Re: no 'writers' section in _security killing me

[Jason Smith <jh...@iriscouch.com>]

You could store the private key in the _user document for the user.
That will be available in the userCtx parameter to
validate_doc_update.

Unfortunately, everybody can read the _users database by default, but
that is easily solved by making it an inbox database.

On Wed, Sep 28, 2011 at 11:38 PM, Jens Alfke <je...@couchbase.com> wrote:
> Oops, yeah, hadn't considered that. (I've been mostly working on signatures, not encryption, and for those the validation fn doesn't need access to a private key.)
>
> --Jens
>
> On Sep 28, 2011, at 9:00 AM, "Zachary Zolton" <za...@gmail.com> wrote:
>
>> For the validation function to decrypt the docs, I'm guessing the
>> private key would have to be in the ddoc. Wouldn't users be able to
>> read that and thus decrypt everything?
>>
>> (Sorry, I've been stalking this thread.)
>>
>>
>> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>>> This would be a great feature; I'd love to see it get in.
>>>
>>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>>>
>>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>>>
>>> --Jens
>>>
>>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>>>
>>>> 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.
>>>>
>>>>    https://issues.apache.org/jira/browse/COUCHDB-1287
>>>>
>>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>>>>>
>>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>>> <ge...@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
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Iris Couch
>>>
>



-- 
Iris Couch

Re: no 'writers' section in _security killing me

[Jens Alfke <je...@couchbase.com>]

Oops, yeah, hadn't considered that. (I've been mostly working on signatures, not encryption, and for those the validation fn doesn't need access to a private key.)

--Jens

On Sep 28, 2011, at 9:00 AM, "Zachary Zolton" <za...@gmail.com> wrote:

> For the validation function to decrypt the docs, I'm guessing the
> private key would have to be in the ddoc. Wouldn't users be able to
> read that and thus decrypt everything?
> 
> (Sorry, I've been stalking this thread.)
> 
> 
> On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
>> This would be a great feature; I'd love to see it get in.
>> 
>> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>> 
>> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>> 
>> --Jens
>> 
>> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>> 
>>> 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.
>>> 
>>>    https://issues.apache.org/jira/browse/COUCHDB-1287
>>> 
>>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>>>> 
>>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>>> <ge...@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
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Iris Couch
>> 

Re: no 'writers' section in _security killing me

[Zachary Zolton <za...@gmail.com>]

For the validation function to decrypt the docs, I'm guessing the
private key would have to be in the ddoc. Wouldn't users be able to
read that and thus decrypt everything?

(Sorry, I've been stalking this thread.)


On Wed, Sep 28, 2011 at 10:22 AM, Jens Alfke <je...@couchbase.com> wrote:
> This would be a great feature; I'd love to see it get in.
>
> There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.
>
> You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.
>
> --Jens
>
> On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:
>
>> 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.
>>
>>    https://issues.apache.org/jira/browse/COUCHDB-1287
>>
>> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>>>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>>>
>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>>> <ge...@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
>>>>>>
>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Iris Couch
>

Re: no 'writers' section in _security killing me

[Jens Alfke <je...@couchbase.com>]

This would be a great feature; I'd love to see it get in.

There is an alternative, though -- the db owner can create an asymmetric key-pair and publish the public key, e.g. as an attachment to a document with a known ID. Writers can then encrypt their messages and post them as attachments to new docs. Even though anyone will be able to see them, only the db owner can decrypt.

You do need decryption in your validation functions, but they can be written in Erlang and call into the standard crypto package.

--Jens

On Sep 28, 2011, at 5:24 AM, "Jason Smith" <jh...@iriscouch.com> wrote:

> 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.
> 
>    https://issues.apache.org/jira/browse/COUCHDB-1287
> 
> On Wed, Jul 20, 2011 at 3:23 AM, Robert Newson <ro...@gmail.com> 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 <ra...@gmail.com> wrote:
>>> 2011/7/19 Javier Rodríguez Escolar <ja...@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 <jh...@iriscouch.com>
>>>> 
>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes
>>>>> <ge...@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
>>>>> 
>>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Iris Couch