#47402 Attribute names are incorrect in search results
Closed: wontfix None Opened 7 years ago by nkinder.

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.

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

3 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

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

15 days ago

Login to comment on this ticket.

Metadata