[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
- To: openldap-its@OpenLDAP.org
- Subject: Re: (ITS#6504) Corrupted control value when using pagedresults with subordinate *ldap* database
- From: masarati@aero.polimi.it
- Date: Fri, 2 Apr 2010 04:44:17 GMT
- Auto-submitted: auto-generated (OpenLDAP-ITS)
> masarati@aero.polimi.it wrote:
>>> masarati@aero.polimi.it wrote:
>>>>> Also, I note that the glued paged response seems to work incorrectly.
>>>>> I
>>>>> made a simple test system, where the root database contains exactly
>>>>> one
>>>>> entry (the suffix) and a back-ldap is glued on top. If I request
>>>>> entries
>>>>> with a page size of 2, searching the suffix return 3 entries;
>>>>> subsequent
>>>>> searches return 2 entries from the proxy. I haven't figured out yet
>>>>> where
>>>>> the issue is.
>>>>
>>>> I figured out how to fix the issue you reported. It is related to the
>>>> fact that slapd internally assumes that ldctl_oid values are constant
>>>> strings, so it doesn't duplicate nor free them. However, control OIDs
>>>> returned by back-ldap (and friends) have been decoded from the wire by
>>>> the
>>>> client library, so they are actually malloc'ed. That's why backglue
>>>> ends
>>>> up with a dangling pointer.
>>>>
>>>> I'm fixing it by having backglue duplicate (and free) control OIDs
>>>> consistently. Another option would be to replace those values with
>>>> constant strings for known control values. This would prevent gluing
>>>> for
>>>> unknown proxied controls.
>>>
>>> Or just tmpalloc them and don't bother to clean them up.
>>
>> Yes, I've reworked all the temporary controls allocation using tmpalloc.
>> Too bad OIDs are char* and not bervals.
>>
>> With respect to the other issue, to honor the requested pagesize we'd
>> need
>> to intercept pagedresult requests, modify the page size in the request
>> when a page crosses two databases, requesting the original page size
>> minus
>> entries already returned. I wonder whether it's worth the effort,
>> though.
>
> IMO pagedresults should be a (global) overlay, and backends shouldn't do
> anything about it. Note that the sssvlv overlay already intercepts
> pagedresults, it's impossible to handle things correctly otherwise.
Well, I've just fixed it. When changing database, I modified the paged
results control value by setting the page size to pagesize -
rs->sr_nentries, with an empty cookie. I'll commit tomorrow, as now I
only have http access.
p.