[Date Prev][Date Next]
Re: (ITS#5628) dereferencing user with translucent overlay
> firstname.lastname@example.org 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) (220.127.116.11)
>> 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/