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

[ando@sys-net.it]

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'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...

p.


Ing. Pierangelo Masarati
OpenLDAP Core Team

SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
-----------------------------------
Office:  +39 02 23998309
Mobile:  +39 333 4963172
Fax:     +39 0382 476497
Email:   ando@sys-net.it
-----------------------------------