Bug 643979 - Strange byte sequence for attribute with no values (nsslapd-referral)
Summary: Strange byte sequence for attribute with no values (nsslapd-referral)
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: 389
Classification: Retired
Component: Directory Server
Version: 1.2.6
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Depends On:
Blocks: 389_1.3.0 690319 781539
TreeView+ depends on / blocked
 
Reported: 2010-10-18 17:47 UTC by Edward Z. Yang
Modified: 2015-01-04 23:44 UTC (History)
5 users (show)

Fixed In Version: 389-ds-base-1.2.10.rc1
Clone Of:
: 781539 (view as bug list)
Environment:
Last Closed: 2012-02-07 16:11:05 UTC
Embargoed:


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

Description Edward Z. Yang 2010-10-18 17:47:09 UTC
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):

    0<14><04><10>nsslapd-referral1<00>0<19><04><12>

Exhibit B (byte sequence containing nsslapd-localhost):

    0,<04><11>nsslapd-localhost1<17><04><15>cats-whiskers.mit.edu0#<04><16>

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):
1.2.6

How reproducible:
Always.

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 15:13:15 UTC
Created attachment 458122 [details]
0001-Bug-643979-Strange-byte-sequence-for-attribute-wit.patch

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
   BER-encoding.

Comment 3 Rich Megginson 2010-11-05 15:21:22 UTC
Comment on attachment 458122 [details]
0001-Bug-643979-Strange-byte-sequence-for-attribute-wit.patch

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 20:37:23 UTC
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 21:06:13 UTC
Comment on attachment 458122 [details]
0001-Bug-643979-Strange-byte-sequence-for-attribute-wit.patch

Excellent.  Thanks for doing the investigation, Endi.

Comment 6 Endi Sukma Dewata 2010-11-08 21:49:52 UTC
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.org/git/389/ds.git
   8db7770..072b7be  master -> master

Comment 7 Amita Sharma 2011-04-13 14:06:32 UTC
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
nsslapd-referralmode:

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 14:26:56 UTC
Looks like a bug - please reopen.

Comment 11 Martin Kosek 2012-01-04 13:30:21 UTC
Upstream ticket:
https://fedorahosted.org/389/ticket/78

Comment 12 Rich Megginson 2012-02-07 16:11:05 UTC
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.