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" <[email protected]> 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 <[email protected]> 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" <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> wrote: >>>>> 2011/7/19 Javier Rodríguez Escolar <[email protected]>: >>>>>> 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 <[email protected]> >>>>>> >>>>>>> On Mon, Jul 11, 2011 at 12:17 PM, Jonathan Geddes >>>>>>> <[email protected]> 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 >>
