Hide Forgot
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.
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 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?
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 on attachment 458122 [details] 0001-Bug-643979-Strange-byte-sequence-for-attribute-wit.patch Excellent. Thanks for doing the investigation, Endi.
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
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?
Looks like a bug - please reopen.
Upstream ticket: https://fedorahosted.org/389/ticket/78
Fixed in 389-ds-base-1.2.10.rc1 now in Fedora/EPEL Testing