This is a multi-part message in MIME format. --------------080305040400020709070605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit
jvcelak@redhat.com wrote:
What happens is that the memberof overlay, when stacked on the frontend database, keeps looping until the stack is exhausted, since internal modifications keep calling the frontend's modify hook rather than the actual one that needs to be called.
I have no idea how to fix it. I probably do not understand the manipulation with BackedInfo structures fully.
It is obious that it is caused by doing a search from the modrdn operation callback memberof_res_modrdn() which is set up in memberof_op_modrdn(). Other backends does not call any backend operation at the same moment (op->callback).
Frontend fe_op_search() is called. It tries to choose the right backend with select_backend(). Which returns the overlay backend (bi_type == "over"), over_op_walk() then selects fe_op_search() again, and we are looping infinitely.
I have no clue how to hide or temporarily deactivate the overlay in memberof_res_modrdn() to make the select_backend() function to choose the right underlaying backend. Or maybe I have choosen a wrong way of fixing it.
All ideas are welcomed. :-)
The attached diff fixes this particular problem. I haven't spent any time to see if the other be_* invocations need to be protected the same way.