Currently, it is possible to require invalid attribute and server will return it.
Steps to Reproduce:
ldapsearch -h <ip> -p 22222 -D "cn=directory manager" -w Secret123 -LL -b "dc=example,dc=com" "uid=tuser6" "objectclass overflow?" -z 15 version: 1
dn: uid=tuser6,ou=People,dc=example,dc=com objectclass overflow?: top objectclass overflow?: person objectclass overflow?: inetorgperson objectclass overflow?: posixAccount objectclass overflow?: smurf objectclass overflow?: organizationalPerson
/usr/lib64/mozldap/ldapsearch -h <ip> -p 22222 -D "cn=directory manager" -w Secret123 -LL -b "dc=example,dc=com" "uid=tuser6" "objectclass overflow?" -z 15 version: 1 dn: uid=tuser6,ou=People,dc=example,dc=com objectclass overflow?: top objectclass overflow?: person objectclass overflow?: inetorgperson objectclass overflow?: posixAccount objectclass overflow?: smurf objectclass overflow?: organizationalPerson
I've investigated the problem and verified it is a pure cosmetic issue and it's not a regression.
If you give the attrs to ldapsearch in "..." like "uid sn junk", it is treated as one attribute. (Note: to separate them, they should not put into the double quotes or each attribute should be in double quotes separately. BAD: ldapsearch ... "uid sn junk" GOOD: ldapsearch ... uid sn junk GOOD: ldapsearch ... "uid" "sn" "junk"
The server receives "uid sn junk" as one attr in do_search: if ( ber_scanf( ber, "{v}}", &attrs ) == LBER_ERROR ) {
(gdb) p attrs[0] $6 = 0x7f3878000e30 "sn uid junk"
The attrs[0] is passed to attr_syntax_normalize_no_lookup, which strips the space and the rest of it and returns just "sn".
But the original attrs[0] is copied into o_searchattrs. operation->o_searchattrs = cool_charray_dup( attrs );
And it is used as name_to_return in send_specific_attrs called from send_ldap_search_entry 1158 name_to_return = op->o_searchattrs[i];
So, in the internal slapi_entry, there is no place to keep the odd attribute list. But of course, o_searchattrs could store looooong garbage strings... p op->o_searchattrs[0] $21 = 0x7f3868001380 "sn lsdjflkwjeglkwjelrjwlkbjlwkjerlwkjerlkwjerlkjsdljlsjblskjerlksjdlfkjsldkfjsldjfsldjfsldkjfsldjflsdfjlsdjflsdkjflkdsjlskdjflskjdflds"
We could fix this in 2 ways... 1) If we receive "uid sn junk" in one attrs[0], we could expand it to attrs[0]="uid", attrs[1]="sn", attrs[2]="junk" and continue. (does this violate ldap?) 2) If we receive "uid sn junk", we copy just first word to operation->o_searchattrs. (do we lose some advantages if any?)
rmeggins@redhat.com wrote: According to rfc 4511, we should ignore this: http://www.ietf.org/rfc/rfc4511.txt
4.5.1.8. SearchRequest.attributes
"If an attribute description in the list is not recognized, it is ignored by the server."
In this case, the attribute description is "sn uid junk", so we should ignore it.
However, I'm sure that if we simply turned off accepting attributes like this, it would break some dumb client somewhere, so we will need to have a switch to turn off/on this behavior.
Bug description: If attribute list passed from the ldapsearch contains a string with a space and following characters, the same string is returned to the client. E.g., ldapsearch -b <basedn> "(filter)" "sn garbage" returns dn: <matched dn> sn garbage: <sn>
Fix description: This patch introduces a config parameter nsslapd-search-return-original-type-switch. It takes on | off. By default, it is off. When it is off, search returns the attribute from which a space and following characters are chopped. dn: <matched dn> sn: <sn> If it is on, it respects the current behaviour and returns the original attribute string.
git patch file (master) 0001-Ticket-604-Required-attribute-not-checked-during-sea.patch
Reviewed by Rich (Thank you!!)
Pushed to master: commit 6602685
Metadata Update from @nhosoi: - Issue assigned to nhosoi - Issue set to the milestone: 1.3.1
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/604
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.