#604 Required attribute not checked during search operation
Closed: wontfix None Opened 11 years ago by nkinder.

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.

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

7 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/604

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)

3 years ago

Login to comment on this ticket.

Metadata