When performing a search that requests the "unhashed#user#password" attribute, the attribute names for the returned values are incorrect. If this attribute is requested as a part of the attribute list, the entire list of attributes afterwards gets shifted off by one.
This bug can be reproduced by installing 389-ds-base-1.2.11 or earlier, creating a DS instance with a suffix of "dc=example,dc=com", then performing this search:
ldapsearch -x -D "cn=directory manager" -w <password> -b "dc=example,dc=com" -s base "objectclass=*" unhashed#user#password nsrole aci nsuniqueid
The results will show the values of the "aci" attribute as the "nsrole" attribute. Similarly, "nsuniqueid" values will be shown as the "aci" attribute:
dn: dc=example,dc=com nsrole: (targetattr!="userPassword")(version 3.0; acl "Enable anonymous access "; allow (read, search, compare) userdn="ldap:///anyone";) nsrole: (targetattr="carLicense || description || displayName || facsimileTele phoneNumber || homePhone || homePostalAddress || initials || jpegPhoto || lab eledURL || mail || mobile || pager || photo || postOfficeBox || postalAddress || postalCode || preferredDeliveryMethod || preferredLanguage || registeredA ddress || roomNumber || secretary || seeAlso || st || street || telephoneNumb er || telexNumber || title || userCertificate || userPassword || userSMIMECer tificate || x500UniqueIdentifier")(version 3.0; acl "Enable self write for co mmon attributes"; allow (write) userdn="ldap:///self";) nsrole: (targetattr ="")(version 3.0;acl "Directory Administrators Group";all ow (all) (groupdn = "ldap:///cn=Directory Administrators, dc=example,dc=com") ;) nsrole: (targetattr="")(version 3.0; acl "Configuration Administrators Group" ; allow (all) groupdn="ldap:///cn=Configuration Administrators,ou=Groups,ou=T opologyManagement,o=NetscapeRoot";) nsrole: (targetattr="")(version 3.0; acl "Configuration Administrator"; allow (all) userdn="ldap:///uid=admin,ou=Administrators,ou=TopologyManagement,o=Ne tscapeRoot";) nsrole: (targetattr = "")(version 3.0; acl "SIE Group"; allow (all) groupdn = "ldap:///cn=slapd-localhost,cn=Red Hat Directory Server,cn=Server Group,cn=l ocalhost.localdomain,ou=localdomain,o=NetscapeRoot";) aci: 2351cd24-d90a11e2-aa0de5ba-aa28d096
This problem seems to affect 389-ds-base-1.2.11 and earlier. Tests against 1.3.1 and master do not exhibit this behavior. I have not tested it against 389-ds-base-1.3.0 yet.
Bug Description: Attribute list given by a client to ldapsearch is first copied to op->o_searchattrs to respect the client input. Then the attribute types are normalized and if the list contains any forbidden attributes, they are removed from the list. When the search result is returned, the internal normalized attribute types are replaced with the original input op->o_searchattrs, respectively. Since forbidden attributes are in op->o_searchattrs but not in the internal attribute list, wrong type from copy is associated to the value and returned to the client.
Fix Description: This patch removes the forbidden attribute before copying the original attribute list to op->o_searchattrs.
Tested with 389-ds-base-1.2.11, RHDS8.2.
Note: 1.3.1 and newer does not have this problem.
git patch file (389-ds-base-1.2.11 branch) 0001-Ticket-47402-Attribute-names-are-incorrect-in-search.patch
Reviewed by Nathan (Thank you!!)
Pushed to 389-ds-base-1.2.11: commit 29236cd
Pushed to 389-ds-base-1.3.0: commit 2980304
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.2.11.22
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/739
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.