Bug 643979 - Strange byte sequence for attribute with no values (nsslapd-referral)
Strange byte sequence for attribute with no values (nsslapd-referral)
Product: 389
Classification: Community
Component: Directory Server (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Rich Megginson
Chandrasekar Kannan
Depends On:
Blocks: 389_1.3.0 690319 781539
  Show dependency treegraph
Reported: 2010-10-18 13:47 EDT by Edward Z. Yang
Modified: 2015-01-04 18:44 EST (History)
5 users (show)

See Also:
Fixed In Version: 389-ds-base-1.2.10.rc1
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 781539 (view as bug list)
Last Closed: 2012-02-07 11:11:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
0001-Bug-643979-Strange-byte-sequence-for-attribute-wit.patch (1.88 KB, patch)
2010-11-05 11:13 EDT, Endi Sukma Dewata
rmeggins: review+
Details | Diff

  None (edit)
Description Edward Z. Yang 2010-10-18 13:47:09 EDT
Description of problem:
I've been using OpenLDAP to talk to Fedora DS, and my bindings
weren't working!  This was quite vexing, so I did some investigation.
I finally pinpointed the error to ldap_get_values_len() returning
a NULL pointer for nsslapd-referral, with no error code.

Sounds sort of like a bug in OpenLDAP, no?  Yes it does, but it's a bug
that's only tickled in very strange circumstances.  If you use ldapvi,
well, that links to OpenLDAP, but it ignores NULLs so that's why you
never see a nsslapd-referral in your cn=config entry.

I made a dump of the buffer that OpenLDAP was parsing values out
of (I think this was what was transmitted over the network.)

Exhibit A (byte sequence containing nsslapd-referral):


Exhibit B (byte sequence containing nsslapd-localhost):


As you can see, the byte sequence for nsslapd-referral appears to have
no textual data associated with it.

Howard responded to the OpenLDAP list with this:

> 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
> Directory Server. [1]

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Attempt to retrieve the cn=config object with the OpenLDAP library and observe the ldap_get_values_len output for nsslapd-referral. If requested, I could probably create a C test script.
Actual results:
nsslapd-referral is sent with weird byte sequence.

Expected results:
nsslapd-referral is omitted from results.
Comment 2 Endi Sukma Dewata 2010-11-05 11:13:15 EDT
Created attachment 458122 [details]

This patch fixes two problems:

1. The cn=config is not supposed to store empty attribute. The
   attrlist_merge_valuearray() has been modified not to create
   a new attribute if the value provided is NULL.

2. If an attribute doesn't have any value, it should not be sent
   to the client. The encode_attr_2() has been modified to check
   whether the attribute has any values before starting to do
Comment 3 Rich Megginson 2010-11-05 11:21:22 EDT
Comment on attachment 458122 [details]

The changes to encode_attr_2() look ok.

Question about attrlist_merge_valuearray() - the change would affect attributes in the real database and in the config dse database - why is it that we don't seem to have this problem with attributes in the real database?
Comment 4 Endi Sukma Dewata 2010-11-08 15:37:23 EST
For LDBM modify replace operation, the attrlist_merge_valuearray() is actually only called for entrydn (which I suppose will never be empty), it's never called for the attributes being replaced. Instead, the LDBM modify will call the attrlist_replace() which will convert empty modify replace operation into a modify delete operation. So the change in attrlist_merge_valuearray() should fix the problem with the config DSE database but will not affect the LDBM database.
Comment 5 Rich Megginson 2010-11-08 16:06:13 EST
Comment on attachment 458122 [details]

Excellent.  Thanks for doing the investigation, Endi.
Comment 6 Endi Sukma Dewata 2010-11-08 16:49:52 EST
Thanks for the review!

Pushed to master:
Counting objects: 13, done.
Compressing objects: 100% (7/7), done.
Writing objects: 100% (7/7), 994 bytes, done.
Total 7 (delta 5), reused 0 (delta 0)
To ssh://edewata@git.fedorahosted.org/git/389/ds.git
   8db7770..072b7be  master -> master
Comment 7 Amita Sharma 2011-04-13 10:06:32 EDT
Hi Rich,

I am testing this bug fix, and got :

[root@amitesthost scripts]# ldapsearch -x -h localhost -p 389 -D "cn=Directory Manager"  -w xyz -b "cn=config" | grep nsslapd-referral

Which I guess violating this rule "The cn=config is not supposed to store empty attribute."

Can you guide me here please?
Comment 8 Rich Megginson 2011-04-13 10:26:56 EDT
Looks like a bug - please reopen.
Comment 11 Martin Kosek 2012-01-04 08:30:21 EST
Upstream ticket:
Comment 12 Rich Megginson 2012-02-07 11:11:05 EST
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing

Note You need to log in before you can comment on or make changes to this bug.