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

[hyc@symas.com]

ando@sys-net.it wrote:
> kouk@noc.uoa.gr wrote:
>> Full_Name: Kostantinos Koukopoulos
>> Version: 2.4.11
>> OS: Solaris 9
>> URL: ftp://ftp.openldap.org/incoming/kostantinos-koukopoulos-080723-2.patch
>> Submission from: (NULL) (195.134.100.30)
>>
>>
>> When using the translucent overlay, if one tries to use set syntax in an ACL or
>> ACI rule, in order to dereference the bound user, like in the example below,
>> then the user's entry is fetched from the local database only.
>>
>> Example<who>  clause:
>> by set="user/eduPersonOrgUnitDN&  [ou=someunit,dc=someorg,dc=somecountry]"
>>
>> If the 'eduPersonOrgUnitDN' attribute has not been modified it will not be found
>> in the local database. I believe it would be better if the remote database was
>> also checked, like when a search operation is performed against the overlay.
>>
>> I found the problem was due to that acl_set_gather2 tries to fetch the attribute
>> directly from the backend, but the translucent overlay does not support this, so
>> the backend is used instead. I've attached a patch which makes acl_set_gather
>> always use an internal search operation to fetch the attribute, instead of
>> calling acl_set_gather2.
>
> Although I understand the spirit of the patch you propose, I'm not sure
> it is the right solution.  In fact, running an internal search like that
> implies that the whole overlay chain be run through.  Probably, that's
> correct in the case of the translucent overlay, though.  I need to think
> about it.  Any comments by others?

Seems that we should add a backend_attribute handler to the translucent overlay.

>> 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/