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:
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
nsrole: (targetattr="")(version 3.0; acl "Configuration Administrator"; allow
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
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)
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: 184.108.40.206
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:
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)
to comment on this ticket.