[Fedora-directory-devel] Re: [Bug 199923] subtree search fails to find items under a db containing special characters

[Noriko Hosoi]

Summary: subtree search fails to find items under a db containing 
special characters

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199923

Bug Description:
When add or import an entry which dn contains '\', subtree search does not return the entry even though the entry satisfies the search criteria.

------- Additional Comments From [e-mail]  2006-10-30 16:47 EST -------
Created an attachment (id=139778)
 --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139778&action=vie...)
sample ldif

step to reproduce:
1) stop slapd
2) import the sample ldif file
3) run subtree search with the filter "(ou=*)" and the attribute list "dn"

expected result:
search result
dn: ou=Accounting, dc=example,dc=com

actual result:
search result
dn: ou=Accounting, dc=example,dc=com
dn: ou=#,+"\>:=<<>;/, dc=example,dc=com
dn: uid=TVradmin0, ou=#,+"\>:=<<>;/, dc=entry,dc=com

------- Additional Comments From [e-mail]  2006-10-30 19:24 EST -------
Created an attachment (id=139786)
 --> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139786&action=vie...)
cvs diffs (ldapserver)

Files:
ldap/servers/slapd/back-ldbm/backentry.c
ldap/servers/slapd/back-ldbm/import-threads.c \
ldap/servers/slapd/back-ldbm/ldbm_add.c \
ldap/servers/slapd/back-ldbm/proto-back-ldbm.h

Bug description:
The directory server internally normalizes the dn and uses the normalized dn to
compare.  In some cases, the server was normalizing the dn more than once. 
Normally, the normalized string is identical to the renormalized dn. { i.e.,
normalized_dn == normalize(normalize_dn) }  The problem is, if the dn contains
'\' (not just the escape character, but it contains some real backslash
characters: dn: ou=#,+"\>:=<<>;/, dc=example,dc=com), the string is
transformed to the one which is not considered to be the same as the original. 
(the normalization is done in the function substr_dn_normalize in slapd/dn.c;
if you are interested in, the function has a detailed comment).

Changes:
Avoid re-normalizing an already normalized dn.	It should be better from the
performance point of view, as well.

Note:
When running ldapsearch having such attribute values containing '"' in it, we
should use single quote to quote the string.  Otherwise, the command line
interface consumes the backslash before '"' and mismatched string is passed to
the server and returns "no such object".
$ dapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
'ou=#,+"\>:=<<>;/, dc=example,dc=com'
'(ou=#,+"\>:=<<>;/)'
version: 1
dn: ou=#,+"\>:=<<>;/, dc=example,dc=com
objectClass: organizationalUnit
objectClass: top
ou: #,+"\>:=<<>;/
ou: #,+">:=<<>;/

$ ldapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
"ou=#,+"\>:=<<>;/, dc=example,dc=com"
"(ou=#,+"\>:=<<>;/)"
ldap_search: No such object

[Fedora-directory-devel] Please review: [Bug 199923] subtree search fails to find items under a db containing special characters

[Noriko Hosoi]

Sorry, I forgot to add the keyword "Please review" to the subject... :p
> Summary: subtree search fails to find items under a db containing 
> special characters
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=199923
>
> Bug Description:
> When add or import an entry which dn contains '\', subtree search 
> does not return the entry even though the entry satisfies the search 
> criteria.
>
> ------- Additional Comments From [e-mail]  2006-10-30 16:47 
> EST -------
> Created an attachment (id=139778)
> --> 
> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139778&action=vie...)
>
> sample ldif
>
> step to reproduce:
> stop slapd
> import the sample ldif file
> run subtree search with the filter "(ou=*)" and the attribute list
>
> "dn"
>
> expected result:
> search result
> dn: ou=Accounting, dc=example,dc=com
>
> actual result:
> search result
> dn: ou=Accounting, dc=example,dc=com
> dn: ou=#,+"\>:=<<>;/, dc=example,dc=com
> dn: uid=TVradmin0, ou=#,+"\>:=<<>;/, dc=entry,dc=com
>
> ------- Additional Comments From [e-mail]  2006-10-30 19:24 
> EST -------
> Created an attachment (id=139786)
> --> 
> (https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=139786&action=vie...)
>
> cvs diffs (ldapserver)
>
> Files:
> ldap/servers/slapd/back-ldbm/backentry.c
> ldap/servers/slapd/back-ldbm/import-threads.c \
> ldap/servers/slapd/back-ldbm/ldbm_add.c \
> ldap/servers/slapd/back-ldbm/proto-back-ldbm.h
>
> Bug description:
> The directory server internally normalizes the dn and uses the 
> normalized dn to
> compare.  In some cases, the server was normalizing the dn more than 
> once. Normally, the normalized string is identical to the renormalized 
> dn. { i.e.,
> normalized_dn == normalize(normalize_dn) }  The problem is, if the dn 
> contains
> '\' (not just the escape character, but it contains some real backslash
> characters: dn: ou=#,+"\>:=<<>;/, dc=example,dc=com), the 
> string is
> transformed to the one which is not considered to be the same as the 
> original. (the normalization is done in the function 
> substr_dn_normalize in slapd/dn.c;
> if you are interested in, the function has a detailed comment).
>
> Changes:
> Avoid re-normalizing an already normalized dn.    It should be better 
> from the
> performance point of view, as well.
>
> Note:
> When running ldapsearch having such attribute values containing '"' in 
> it, we
> should use single quote to quote the string.  Otherwise, the command line
> interface consumes the backslash before '"' and mismatched string is 
> passed to
> the server and returns "no such object".
> $ dapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
> 'ou=#,+"\>:=<<>;/, dc=example,dc=com'
> '(ou=#,+"\>:=<<>;/)'
> version: 1
> dn: ou=#,+"\>:=<<>;/, dc=example,dc=com
> objectClass: organizationalUnit
> objectClass: top
> ou: #,+"\>:=<<>;/
> ou: #,+">:=<<>;/
>
> $ ldapsearch -p <port> -D "cn=Directory Manager" -w <pw> -b
> "ou=#,+"\>:=<<>;/, dc=example,dc=com"
> "(ou=#,+"\>:=<<>;/)"
> ldap_search: No such object