Bug in V3.1 ud handling attributes with null values

Pete Donahue, DPE, LKG2-2/Z7 (donahue@tuxedo.enet.dec.com)
Wed, 8 Mar 95 10:53:17 EST

While debugging a problem with our ldap server, we stumbled upon our own
bug - our server fails to return attributes from a search request once
it sees a returned attribute with no values. This is a rare case. We've
only seen it with the userpassword attribute - our DSA will return the
attribute with no values if either:
- the search request specified that the server return all attributes
- the search requested that the server return the userpassword

(My interpretation of the X.511 recommendation is that our DSA is behaving

In order to fix this problem we modified our ldap server to return the
attribute with a null value.

When I tested our modified ldap server against ud from your 3.1 release,
ud got a segmentation fault. Routine add_values in print.c does not check
for 0 after it calls ldap_count_values. It should check and skip the
processing of any values.

The reason that your latest version of ud stumbles on this problem and
previous versions don't, is that the latest version requests that the
userpassword attribute be returned. Previous versions didn't request
this attribute.

Below is a diff of the changes I made to print.c to correct the ud problem:

*** print.c Wed Mar 8 10:37:15 1995
--- print.c.orig Wed Mar 8 10:36:53 1995
*** 121,133 ****
* Fill in the attribute structure for this attribute. This
* stores away the values (using strdup()) and the count. Terminate
* the list with a NULL pointer.
attr->number_of_values = ldap_count_values(vp);
- if (attr->number_of_values > 0) {
attr->quipu_name = strdup(ap);
if ((attr->values = (char **) malloc((unsigned) ((attr->number_of_values + 1) * sizeof(char *)))) == (char **) NULL) {
--- 121,130 ----
*** 149,161 ****
*avp++ = strdup(*tp);
- } /* End of num_values > 0 */
*avp = NULL;

--- 146,155 ----