[Date Prev][Date Next]
Re: (ITS#5628) dereferencing user with translucent overlay
Pierangelo Masarati wrote:
> email@example.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/