openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠fast-mail.org 11 Sep '17

11 Sep '17

Hi Bryan, Unfortunately this patch is no longer available with Apple's switch to iCloud. Would you be able to upload it to the OpenLDAP FTP server? Thanks, Quanah

1 0

(ITS#8729) saslregex mapping failure
by mikedotjackson＠gmail.com 11 Sep '17

11 Sep '17

Full_Name: Mike Jackson Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.157.185.162) On an server with KRB5_KTNAME and KRB5CCNAME in it's environment but without a functional /etc/krb5.conf file, olcAuthzRegexp mappings are completely ignored for EXTERNAL auth (in my tests, distinguished names for X.509 client authentication were not remapped until OL was able to kinit it's own kerberos ticket). This is a bit of a corner case, but a pretty annoying bug nonetheless when building up new servers and indicates a failure in logic somewhere or another. Chat logs follow: JoBbZ: podz: oh, you're saying that the regex fails if you use a *non* GSSAPI mechanism, and the krb5.conf can't talk to a KDC? [9:41pm] podz: yes [9:41pm] podz: and this is a dysfunction [9:41pm] JoBbZ: yes, that'd be a bug for sure [9:41pm] podz: it's really a dysfunction [9:42pm] JoBbZ: well, there should be zero reason for GSSAPI to even be initialized if using EXTERNAL [9:42pm] podz: precisely [9:42pm] tarpman: that's sounding more like a sasl bug so far... [9:42pm] podz: tarpman: like i said, i am not sure where the bug lies [9:43pm] podz: something is fishy, though [9:43pm] podz: now i am going to eat some cake and be back in 20-30 mins [9:44pm] JoBbZ: well, EXTERNAL is all openldap code, doesn't depend on cyrus-sasl [9:45pm] JoBbZ: so it could be a bug in OpenLDAP that it is calling cyrus-sasl at all in this case [9:45pm] podz: probably you are right

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by quanah＠symas.com 11 Sep '17

11 Sep '17

Hi Alan, Did you get a chance to finish the patch? Thanks, Quanah --On Tuesday, August 09, 2016 5:49 PM +0000 alcronin(a)cisco.com wrote: > SGksDQoNCkkgY2FuIHRha2UgYSBsb29rIGF0IHRoZSBzbGFwZCBzaWRlIGFuZCB0aG9zZSBvd > Ghl > ciByZXF1ZXN0cyBhbmQgaW1wbGVtZW50IHRoZSBmaXggdGhlcmUgYXMgd2VsbC4gSWYgdGhlc > mUg > YXJlIGFueSBvdGhlciBhcmVhcyBsZXQgbWUga25vdyBhbmQgSSBjYW4gYWRkcmVzcyB0aGVtI > HRv > LiBJIHdpbGwgdXBkYXRlIHRoZSBwYXRjaCB3aGVuIEkgaGF2ZSB0aG9zZSBjaGFuZ2VzIHJlY > WR5 > Lg0KDQpUaGUgY29tcGlsZXJzIHdpbGwgdHJlYXQgdGhhdCAobWVtc2V0IGJlaGF2aW91cikgY > XMg > YW4gb3B0aW1pemF0aW9uIGFuZCB3b3VsZCBiZSBoZXNpdGFudCB0byBjaGFuZ2UgaXQuIFRoa > XMg > aXMgbW9zdGx5IHNlZW4gaW4gR0NDIGFuZCBhbnkgdmFyaWFudHMuIFRoZXJlIGFyZSBvdGhlc > iBv > cHRpbWlzYXRpb25zIHN1Y2ggYXMgcmVtb3ZpbmcgdGhlIGNhbGwgdG8gdGhlIG1ldGhvZCBlb > nRp > cmVseSBpZiB0aGUgbmV4dCBvcGVyYXRpb24gaXMgYSBmcmVlIGFzIHRoaXMgd291bGQgYmUgc > 2Vl > biBieSB0aGUgY29tcGlsZXIgYXMgYSBuby1vcC4gUmVtb3Zpbmcgb3B0aW1pc2F0aW9ucyBpc > yBu > b3QgaWRlYWwgYXMgaXQgY2FuIGFmZmVjdCBtb3JlIHRoYW4ganVzdCB0aGUgc2VjdGlvbiBvZ > iB0 > aGUgY29kZSBhbmQgaXMgbm90IGEgY3Jvc3MgcGxhdGZvcm0gc29sdXRpb24uDQoNClRoYW5rc > ywN > CkFsYW4NCg0KT24gMDgvMDgvMjAxNiwgMjE6MzcsICJIb3dhcmQgQ2h1IiA8aHljQHN5bWFzL > mNv > bT4gd3JvdGU6DQoNCiAgICBBbGFuIENyb25pbiAoYWxjcm9uaW4pIHdyb3RlOg0KICAgID4gS > Gkg > SG93YXJkLA0KICAgID4NCiAgICA+IEkgY2FuIGNoYW5nZSB0aGUgY29kZSBzbyB0aGF0IGl0I > G92 > ZXJ3cml0ZXMgdGhlIG1lbW9yeSBmcm9tDQogICAgbGRhcF9mcmVlX3JlcXVlc3RfaW50KCkga > W5z > dGVhZC4gVGhpcyB3aWxsIGNvdmVyIHRoZSBleGVjdXRpb24gdXNpbmcgYSBiaW5kDQogICAgK > GJv > dGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cykuIElzIHRoZXJlIGFueSBvdGhlciBwb > GFj > ZXMgd2hlcmUgdGhlDQogICAgcGFzc3dvcmQgd291bGQgYmUgaW4gdGhlIGJ1ZmZlciB0aGF0I > G5l > ZWRzIHRvIGJlIGNsZWFyZWQ/IFRoZSByZWFzb24gZm9yDQogICAgaW5zZXJ0aW5nIGl0IGlud > G8g > YmVyX2ZyZWVfYnVmKCkgd2FzIHRoYXQgaXQgd291bGQgY2xlYXIgYWxsIHBsYWNlcy4NCiAgI > CAN > CiAgICBJIHNlZSwgeW91J3JlIGxvb2tpbmcgYXQgdGhlIGNsaWVudCBzaWRlLiBXaGF0IGFib > 3V0 > IHRoZSBzbGFwZCBzaWRlPw0KICAgIA0KICAgIFRoZXJlIGFyZSAyIG1haW4gcGxhY2VzIHdoZ > XJl > IHBhc3N3b3JkcyBvY2N1ciAtIEJpbmQsIGFuZCBQYXNzd29yZE1vZGlmeSBleG9wLiANCiAgI > CBU > aGV5IG1pZ2h0IGFsc28gb2NjdXIgaW4gQWRkIGFuZCBNb2RpZnkgcmVxdWVzdHMuIEFkZCBpc > yBu > b3Qgc28gdW51c3VhbCwgDQogICAgTW9kaWZ5IHNob3VsZCBub3QgaGFwcGVuIHNpbmNlIGNsa > WVu > dHMgc2hvdWxkIHVzZSBQYXNzd29yZE1vZGlmeSBpbnN0ZWFkLg0KICAgIA0KICAgID4gU29tZ > SBj > b21waWxlcnMgd2lsbCBvcHRpbWl6ZSBjYWxscyB0byBtZW1zZXQoKSBzbyB0aGF0IG9ubHkgd > Ghl > IGZpcnN0DQogICAgY2hhcmFjdGVyIHdpbGwgYmUgY2hhbmdlZC4gTGVhdmluZyB0aGUgcmVzd > CBv > ZiB0aGUgc3RyaW5nIGludGFjdC4NCiAgICANCiAgICBUaGF0J3MgY2xlYXJseSBhIGNvbXBpb > GVy > IGJ1ZyB0aGVuLiBJZiB5b3UgaGF2ZSBleGFtcGxlcyBvZiBzdWNoIHNpdHVhdGlvbnMgDQogI > CAg > eW91IHNob3VsZCByZXBvcnQgdGhhdCB0byB0aGUgcmVzcGVjdGl2ZSBjb21waWxlciBtYWlud > GFp > bmVycy4NCiAgICANCiAgICA+IFRoaXMgaXMgd2h5DQogICAgdGhlIGl0ZXJhdGlvbiBpcyBpb > iBw > bGFjZS4NCiAgICA+DQogICAgPiBUaGFua3MgZm9yIGxvb2tpbmcgaW50byB0aGlzIHBhdGNoL > g0K > ICAgID4NCiAgICA+IEFsYW4NCiAgICA+DQogICAgPiBPbiAwNS8wOC8yMDE2LCAxOTo1MCwgI > khv > d2FyZCBDaHUiIDxoeWNAc3ltYXMuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiAgICAgIGFsY > 3Jv > bmluQGNpc2NvLmNvbSB3cm90ZToNCiAgICA+ICAgICAgPiBGdWxsX05hbWU6IEFsYW4gQ3Jvb > mlu > DQogICAgPiAgICAgID4gVmVyc2lvbjogMi40LjQ0DQogICAgPiAgICAgID4gT1M6IFdpbmRvd > 3Mg > OC4xDQogICAgPiAgICAgID4gVVJMOiBodHRwczovL2RsLmRyb3Bib3h1c2VyY29udGVudC5jb > 20v > dS84MjM0MzQ3NS9TZWN1cmVseUVyYXNlQnVmZmVyLmRpZmYNCiAgICA+ICAgICAgPiBTdWJta > XNz > aW9uIGZyb206IChOVUxMKSAoMjAwMTo0MjA6NDA0MToyMDAzOmY5NDI6NTlhNTo1NDVmOmIzM > zQp > DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IFRoZSBmb2xsb3dpb > mcg > cGF0Y2ggaXMgYSBtb2RpZmljYXRpb24gdG8gdGhlIE9wZW5MREFQIEJlckVsZW1lbnQgYnVmZ > mVy > LiBUaGUNCiAgICA+ICAgICAgPiBidWZmZXIgY2FuIGJlIHVzZWQgdG8gY29udGFpbiB0aGUgT > ERB > UCByZXF1ZXN0IGluY2x1ZGluZyB0aGUgcGFzc3dvcmQgZm9yDQogICAgPiAgICAgID4gYXV0a > GVu > dGljYXRpb24uIFdoaWxlIHRoaXMgaXMgZnJlZSdkIHdoZW4gaXQgaXMgbm8gbG9uZ2VyIG5lZ > WRl > ZCwgdGhlIGNvbnRlbnRzDQogICAgPiAgICAgID4gb2YgdGhlIGJ1ZmZlciBpcyBub3Qgb3Zlc > ndy > aXR0ZW4gZnJvbSBtZW1vcnkuIFRoaXMgY2FuIGxlYWQgdG8gc29tZW9uZSByZWFkaW5nDQogI > CAg > PiAgICAgID4gdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBhbmQgZGV0ZXJtaW5pbmcgd2hhd > CB0 > aGUgcGFzc3dvcmQgaXMuIFRoZSBjaGFuZ2UNCiAgICA+ICAgICAgPiBpbmNsdWRlZCBpbiB0a > Glz > IHBhdGNoIHdpbGwgaXRlcmF0ZSBvdmVyIHRoZSBtZW1vcnkgYW5kIGNsZWFyIGl0LiBUaGlzI > Hdp > bGwNCiAgICA+ICAgICAgPiByZW1vdmUgYW55IHRyYWNlIG9mIHRoZSBwYXNzd29yZCBieSB0a > GUg > dGltZSBleGVjdXRpb24gaXMgaGFuZGVkIGJhY2sgdG8gdGhlDQogICAgPiAgICAgID4gY2Fsb > GVy > Lg0KICAgID4NCiAgICA+ICAgICAgV2h5IHdvdWxkIHlvdSBpbnNlcnQgYSBwZXJmb3JtYW5jZ > SBw > ZXNzaW1pemF0aW9uIGludG8gZXZlcnkgdXNlIG9mIHRoZSBMQkVSDQogICAgPiAgICAgIGxpY > nJh > cnksIHJhdGhlciB0aGFuIGp1c3QgZXJhc2luZyB0aGUgcGFzc3dvcmQgZnJvbSBhIEJpbmQgc > mVx > dWVzdD8NCiAgICA+DQogICAgPiAgICAgIFdoeSB3b3VsZCB5b3UgdXNlIGFuIGV4cGxpY2l0b > Hkg > Y29kZWQgbG9vcCBzZXR0aW5nIG9uZSBjaGFyYWN0ZXIgYXQgYSB0aW1lLA0KICAgID4gICAgI > CBp > bnN0ZWFkIG9mIHVzaW5nIGxpYmMncyBtZW1zZXQoKSB3aGljaCBoYXMgcHJvYmFibHkgYmVlb > iB3 > ZWxsIG9wdGltaXplZD8NCiAgICA+DQogICAgPiAgICAgID4gVGhlIGF0dGFjaGVkIHBhdGNoI > GZp > bGUgaXMgZGVyaXZlZCBmcm9tIE9wZW5MREFQIFNvZnR3YXJlLiBBbGwgb2YgdGhlDQogICAgP > iAg > ICAgID4gbW9kaWZpY2F0aW9ucyB0byBPcGVuTERBUCBTb2Z0d2FyZSByZXByZXNlbnRlZCBpb > iB0 > aGUgZm9sbG93aW5nIHBhdGNoKGVzKSB3ZXJlDQogICAgPiAgICAgID4gZGV2ZWxvcGVkIGJ5I > EFs > YW4gQ3JvbmluIGFsY3JvbmluQGNpc2NvLmNvbS4gSSBoYXZlIG5vdCBhc3NpZ25lZCByaWdod > HMg > YW5kL29yDQogICAgPiAgICAgID4gaW50ZXJlc3QgaW4gdGhpcyB3b3JrIHRvIGFueSBwYXJ0e > S4N > CiAgICA+ICAgICAgPiBUaGUgYXR0YWNoZWQgZmlsZSBpcyBkZXJpdmVkIGZyb20gT3BlbkxEQ > VAg > U29mdHdhcmUuIEFsbCBvZiB0aGUgbW9kaWZpY2F0aW9ucyB0bw0KICAgID4gICAgICA+IE9wZ > W5M > REFQIFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlc > mUg > ZGV2ZWxvcGVkIGJ5IENpc2NvDQogICAgPiAgICAgID4gU3lzdGVtcywgSW5jLi4gQ2lzY28gU > 3lz > dGVtcywgSW5jLiBoYXMgbm90IGFzc2lnbmVkIHJpZ2h0cyBhbmQvb3IgaW50ZXJlc3QgaW4NC > iAg > ICA+ICAgICAgPiB0aGlzIHdvcmsgdG8gYW55IHBhcnR5LiBJLCBBbGFuIENyb25pbiBhbSBhd > XRo > b3JpemVkIGJ5IENpc2NvIFN5c3RlbXMsIEluYy4sIG15DQogICAgPiAgICAgID4gZW1wbG95Z > XIs > IHRvIHJlbGVhc2UgdGhpcyB3b3JrIHVuZGVyIHRoZSBmb2xsb3dpbmcgdGVybXMuDQogICAgP > iAg > ICAgID4gQ2lzY28gU3lzdGVtcywgSW5jLiBoZXJlYnkgcGxhY2UgdGhlIGZvbGxvd2luZyBtb > 2Rp > ZmljYXRpb25zIHRvIE9wZW5MREFQDQogICAgPiAgICAgID4gU29mdHdhcmUgKGFuZCBvbmx5I > HRo > ZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21haW4uIEhlbmNlLCB0aGVzZ > Q0K > ICAgID4gICAgICA+IG1vZGlmaWNhdGlvbnMgbWF5IGJlIGZyZWVseSB1c2VkIGFuZC9vciByZ > WRp > c3RyaWJ1dGVkIGZvciBhbnkgcHVycG9zZSB3aXRoIG9yDQogICAgPiAgICAgID4gd2l0aG91d > CBh > dHRyaWJ1dGlvbiBhbmQvb3Igb3RoZXIgbm90aWNlLg0KICAgID4gICAgICA+DQogICAgPiAgI > CAg > ID4NCiAgICA+DQogICAgPg0KICAgID4gICAgICAtLQ0KICAgID4gICAgICAgICAtLSBIb3dhc > mQg > Q2h1DQogICAgPiAgICAgICAgIENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d > 3cu > c3ltYXMuY29tDQogICAgPiAgICAgICAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAgIGh0d > HA6 > Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KICAgID4gICAgICAgICBDaGllZiBBcmNoaXRlY3QsI > E9w > ZW5MREFQICBodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9wcm9qZWN0Lw0KICAgID4NCiAgICA+D > Qog > ICAgDQogICAgDQogICAgLS0gDQogICAgICAgLS0gSG93YXJkIENodQ0KICAgICAgIENUTywgU > 3lt > YXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICAgICAgRGlyZWN0b > 3Is > IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvDQogICAgICAgQ > 2hp > ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjd > C8N CiAgICANCg0K > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠symas.com 11 Sep '17

11 Sep '17

--On Monday, April 04, 2016 7:57 PM +0000 Frank.Swasey(a)uvm.edu wrote: > The bad log entries that coincide with check_syncrepl finding the replica > has fallen behind are like: > > Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > > They appear once an hour. Hi Frank, This looks like ITS#8444, which now has a fix checked into OpenLDAP master. You probably want to apply it to your deployment. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8728) MDB_VL32 bug deleting overflow pages
by hyc＠openldap.org 09 Sep '17

09 Sep '17

Full_Name: Howard Chu Version: mdb.master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.114) Submitted by: hyc The cursor's mc_ovpg pointer must be cleared after freeing a dirty overflow page, otherwise a use-after-free can occur later.

1 0

Re: (ITS#8722) MDB_LAST_DUP/FIRST_DUP return item beyond last item
by h.b.furuseth＠usit.uio.no 08 Sep '17

08 Sep '17

mdb_cursor_del()'s NUMKEYS() check in your fix (f34b61f9471d1c03fe0517b9d817c50c920e378a) looks like a general cursor tracking issue, so XCURSOR_REFRESH() should check it too. Unless we've got some ugliness where mp_lower is temporarily too small, but I haven't spotted anything like that. The mdb_cursor_del() is still wrong: The mn_flags check doesn't skip non-DUPDATA nodes. Using XCURSOR_REFRESH() fixes it. And it should use XCURSOR_INITED() like other XCURSOR_REFRESH() callers. Suggested fixes - branch "xcursor-its8722" @ symas.

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by quanah＠symas.com 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 7:27 PM +0000 michael(a)stroeder.com wrote: > Is there anything wrong with the patch herein? Hi Michael, I've added this to my openldap-scratch repo where I'm pulling in patches for review for inclusion into the overall project. I'll be sending out an email to -devel soon covering all the ITSes I have queued up needing review. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 08 Sep '17

08 Sep '17

Is there anything wrong with the patch herein?

1 0

(ITS#8727) Potential memory leaks in ldap_send_server_request()
by hyc＠openldap.org 08 Sep '17

08 Sep '17

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.114) Submitted by: hyc There are two error paths don't call ber_free() as all the other ones do. One is only in LDAP_CONNECTIONLESS code so quite rare. One occurs if ldap_int_flush_request() fails when flushing an earlier partial write. Also quite rare but has been seen occasionally.

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by quanah＠symas.com 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 1:02 PM +0000 a.cudbardb(a)freeradius.org wrote: >> Thanks for the report and sorry for the delay on getting to this = > issue. I would note that for the fix to be included in the OpenLDAP = > project, we need an IPR statement, as noted at = > <https://www.openldap.org/devel/contributing.html>. If you can provide = > that, and (if possible) submit the patch as git format-patch via the = > project FTP server (include the URL in your email), then I can pull it = > in. > > IPR statement is not a problem, but I don't have the original diff to = > work from. If you can send me a copy of the FTP submission I can = > reformat it and resubmit it. Hi Arran, The diff is in your github issues tracker. ;) <https://github.com/arr2036/ldapperf/issues/2#issuecomment-66242732> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs