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 <[email protected]> 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" <[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 >>> > -- Iris Couch
