Re: (ITS#5628) dereferencing user with translucent overlay

[hyc@symas.com]

Pierangelo Masarati wrote:
> hyc@symas.com wrote:
>
>> Seems that we should add a backend_attribute handler to the translucent overlay.
>
> That's not going to work anyway, since the overlay's bi_acl_attribute
> method is not going to be called anyway.  In fact, any call to
> backend_attribute will be cast into a call to bi_entry_get_rw, so only
> by implementing translucent_entry_get_rw we could have a chance to look
> the remote entry up.  But then we'd probably have issues in the
> subsequent call to translucent_entry_release, to distinguish whether the
> looked-up entry was from the local or the remote database...  And see
> ITS#5650: right now, even if the attribute is not local, the local entry
> will always be returned.

I think in most cases the entry that translucent returns will have to be 
constructed from both local and remote anyway. In which case, 
translucent_release should just be a call to entry_free; the original local 
entry should be duplicated and released immediately.

>>>> I've also tried to hack the translucent overlay so that it would support the
>>>> bi_entry_get_rw callback but I haven't been able to provide something that would
>>>> even satisfy me. I suppose I would have to use some sort of callback mechanism
>>>> like translucent_search_cb but I haven't figured it out yet.
>>> That's another problem I ran through when trying to add rewrite
>>> capabilities to the slapo-rwm(5) overlay, so that authorization could be
>>> rewrapped when performed through virtual data views.  However, I believe
>>> the API of bi_entry_get_rw be modified for overlays, since the current
>>> API does not allow calls to modify their arguments.  I'd leave that
>>> alone by now.
>> Haven't looked closely at this yet...

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/