[Date Prev][Date Next]
Re: Possible bug in ldap_get_values_len?
Edward Z. Yang wrote:
I was mucking around with OpenLDAP and noticed that ldap_get_values_len
was returning NULL without setting a corresponding error code. Intruiged
by this behavior, I did some debugging, and found that it was doing so
on nsslapd-referral as generated by a Fedora 1.2.5 or 1.2.6 directory server
for the cn=config entry (I haven't checked anywhere else yet). Here
is a fragment of the byte sequence in ber_buf that was causing this:
I checked some other code, ldapvi works around this by checking if the return
value of ldap_get_values_len is NULL before using it, but it doesn't seem to
do so consistently, and an old version of the code had this to say:
struct berval **values = ldap_get_values_len(ld, entry, ad);
struct berval **ptr;
if (!values) continue; /* weird server */
I've also posted to 389-users , in Fedora Directory Server spitting out
malformed data. But in that case, OpenLDAP should give me an error code,
or work around it, or something.
Looking at the code and your data snippet, this is because your BER sequence
says it's got a set of zero values. In this case, ber_scanf doesn't bother to
allocate any memory to store the values, since there would be no point.
Technically there's no error here; sets are allowed to be empty. (E.g., if you
had done an attrsOnly search then all of the attributes would have zero sets
for their values.) So no, it's not a bug that libldap returns NULL instead of
a pointer. And no, libldap shouldn't report an error code here either.
But it's certainly stupid for the server to attach the attribute to the
response with no values, since this is obviously NOT an attrsOnly search
response. Sounds like you ought to file a bug report against the Fedora
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/