#47722 rsearch filter error on any search filter
Closed: wontfix Opened by nkinder.

Any attempt to run rsearch with a filter fails with error=0xFFFFFFF9 (i.e.
LDAP_FILTER_ERROR (-7)).

Version-Release number of selected component (if applicable):
389-ds-base-1.2.11.15-31.el6_5.x86_64

Steps to Reproduce:
rsearch -D "cn=Directory Manager" -w password -s "dc=example,dc=com" -f
"ou=people"
rsearch -D "cn=Directory Manager" -w password -s "dc=example,dc=com" -f
"ou=Groups"
rsearch -D "cn=Directory Manager" -w password -s "dc=example,dc=com" -f
"uid=joe"
(whatever filter used; scope is the db suffix here)

Actual results:
1) rsearch output:
rsearch: 1 threads launched.

T1: failed to search 2, error=0xFFFFFFF9
20140227 12:29:01 - Rate: 0.00/thr ( 0.00/sec = infms/op), total: 0
(1 thr)
T1 no heartbeat (waiting)
20140227 12:29:11 - Rate: 0.00/thr ( 0.00/sec = infms/op), total: 0
(1 thr)
T1 no heartbeat -- Dead thread being reaped.
20140227 12:29:21 - Rate: -nan/thr ( 0.00/sec = infms/op), total: 0
(0 thr)
All threads died. (?)

2) access log of directory server logs only:
[27/Feb/2014:12:28:50 +0100] conn=32681 fd=64 slot=64 connection from ::1 to
::1
[27/Feb/2014:12:28:50 +0100] conn=32681 op=0 BIND dn="cn=Directory Manager"
method=128 version=2
[27/Feb/2014:12:28:50 +0100] conn=32681 op=0 RESULT err=0 tag=97 nentries=0
etime=0 dn="cn=directory manager"
[27/Feb/2014:12:29:20 +0100] conn=32681 op=-1 fd=64 closed - B1

i.e. no SRCH operation


The problem here is that a NULL gets added onto the end of the search filter in the rsearch code:


390 sprintf(filterBuffer, "%s%s", filter, s);
(gdb) p s
$5 = 0x0
(gdb) p filter
$6 = 0x7fffffffe356 "(ou=people)"
(gdb) n
391 pFilter = filterBuffer;
(gdb) p filterBuffer
$7 = "(ou=people)(null)", '\000' "\367, ",


The fix is simple:

--- a/ldap/servers/slapd/tools/rsearch/searchthread.c
+++ b/ldap/servers/slapd/tools/rsearch/searchthread.c
@@ -387,7 +387,7 @@ static int st_search(SearchThread *st)
sprintf(num, "%d", get_large_random_number() % numeric);
s = num;
}
- sprintf(filterBuffer, "%s%s", filter, s);
+ sprintf(filterBuffer, "%s%s", filter, s ? s : "");
pFilter = filterBuffer;
} else {
pFilter = filter;

git merge ticket47722
Updating 76acff1..8afcf90
Fast-forward
ldap/servers/slapd/tools/rsearch/searchthread.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)

git push origin master
76acff1..8afcf90 master -> master

commit 8afcf90b0d9d6599144bb1666ca79cef9e91b3ef
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Mar 11 11:17:53 2014 -0400

64d91ed..f426173 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

acd0327..a6ec86d 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

9ac3edb..6c824d8 389-ds-base-1.3.0 -> 389-ds-base-1.3.0

7c0fc93..0aa38a2 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

{{{
411 ntable = nt_new(0);
}}}
Is ntable initialized to NULL?

{{{
300 299 while (1) {
301 int ret = ldap_search_ext_s(st->ld2, suffix, scope, pFilter,
300 int ret = ldap_search_ext_s(st->ld2, suffix, scope, filterBuffer,
302 301 NULL, attrsOnly, NULL, NULL,
303 302 &timeout, -1, &result);
303 PR_smprintf_free(filterBuffer);
}}}
This is freed inside a while loop - is it reallocated below?

{{{
438 char *description;
}}}
Is it possible for this to be freed without being set?

Replying to [comment:10 rmeggins]:

{{{
411 ntable = nt_new(0);
}}}
Is ntable initialized to NULL?

Yes.

{{{
300 299 while (1) {
301 int ret = ldap_search_ext_s(st->ld2, suffix, scope, pFilter,
300 int ret = ldap_search_ext_s(st->ld2, suffix, scope, filterBuffer,
302 301 NULL, attrsOnly, NULL, NULL,
303 302 &timeout, -1, &result);
303 PR_smprintf_free(filterBuffer);
}}}
This is freed inside a while loop - is it reallocated below?

No, this is bad and needs to be changed.

{{{
438 char *description;
}}}
Is it possible for this to be freed without being set?

No.

Replying to [comment:11 mreynolds]:

Replying to [comment:10 rmeggins]:

{{{
411 ntable = nt_new(0);
}}}
Is ntable initialized to NULL?

Yes.

{{{
300 299 while (1) {
301 int ret = ldap_search_ext_s(st->ld2, suffix, scope, pFilter,
300 int ret = ldap_search_ext_s(st->ld2, suffix, scope, filterBuffer,
302 301 NULL, attrsOnly, NULL, NULL,
303 302 &timeout, -1, &result);
303 PR_smprintf_free(filterBuffer);
}}}
This is freed inside a while loop - is it reallocated below?

No, this is bad and needs to be changed.

{{{
438 char *description;
}}}
Is it possible for this to be freed without being set?

No.

Ok, new patch is attached.

git merge ticket47722
Updating 8afcf90..2ec0cdb
Fast-forward
ldap/servers/slapd/tools/rsearch/rsearch.c | 11 +++---
ldap/servers/slapd/tools/rsearch/searchthread.c | 40 ++++++++++++++--------
2 files changed, 31 insertions(+), 20 deletions(-)

git push origin master

8afcf90..2ec0cdb master -> master

commit 2ec0cdb295e145bff60d020708339c77b10a9367
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Mar 11 14:35:53 2014 -0400

f426173..dee6ed1 389-ds-base-1.3.2 -> 389-ds-base-1.3.2

a6ec86d..a433ed7 389-ds-base-1.3.1 -> 389-ds-base-1.3.1

6c824d8..e118eab 389-ds-base-1.3.0 -> 389-ds-base-1.3.0

0aa38a2..1361c27 389-ds-base-1.2.11 -> 389-ds-base-1.2.11

f12e121..fb22b38 master -> master
commit fb22b387e4376caae35121a645a5879dbac7b4fb
Author: Mark Reynolds mreynolds@redhat.com
Date: Tue Dec 9 15:29:07 2014 -0500

7b32ab0..4002f3b 389-ds-base-1.3.3 -> 389-ds-base-1.3.3
commit 4002f3b946f567994de6c32c6ff713b1d341a975

0f210a7..09eff3d 389-ds-base-1.3.2 -> 389-ds-base-1.3.2
commit 09eff3df1081c22d6b74f1f4414006766e2802bc

53df6b2..250fc63 389-ds-base-1.3.1 -> 389-ds-base-1.3.1
commit 250fc6347a452ea2369bbd26e6c5d2d8d760dcb9

c724541..912deee 389-ds-base-1.2.11 -> 389-ds-base-1.2.11
commit 912deee98a1a5f59732a41a7bf05d29060d225ba

Metadata Update from @mreynolds:
- Issue assigned to mreynolds
- Issue set to the milestone: 1.2.11.26

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/1056

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Metadata Update from @spichugi:
- Issue close_status updated to: wontfix (was: Fixed)

Metadata