openldap-bugs April 2019

openldap-bugs@openldap.org

16 participants
64 discussions

(ITS#9015) Replication goes haywire querying promoted master
by quanah＠openldap.org 23 Apr '19

23 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) In testing a particular use case/setup scenario, I found that it's possible to cause a replica to slam a provider with unending requests. In this specific case, I was setting up delta-syncrepl MMR, but I believe the issue applies to standard syncrepl, and is not MMR specific. The scenario looks like this: Initially we have a stand alone server, which no overlays in place. The configuration is done via cn=config, which allows for us to update the configuration without a server restart. The configuration is modified to load the syncprov and accesslog overlays, create a new accesslog database, and to send all change data to the accesslog db. After that is done, a secondary server is brought online with the same configuration other than the serverID being different and the syncrepl statement adjusted. When the secondary server is started, it pummels the initial provider with queries like: Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(objectClass=*)" Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SRCH attr=* + Apr 23 06:39:06 anvil4 slapd[28967]: conn=1003 op=361868131 SEARCH RESULT tag=101 err=0 nentries=0 text= (Averaging around 2000 queries/second on my server per syncrepl client). I believe the problem is that the root entry for the database contains no contextCSN. This is likely due to the fact that: a) There was never a syncprov overlay present until I loaded this one in b) The serverID was set prior to the syncprov overlay being loaded (So it went from "0" to "1", with no changes ever recorded for "1"). Now there is a trivial ways to handle this, by making a change on the provider prior to starting up the other servers. However, I think the overall behavior is undesirable. If there is no contextCSN present, it should not lead to replication clients executing a potential DoS on the provider. It also generated ~60GB of logs at loglevel stats in 1 day.

1 0

Re: (ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by hyc＠symas.com 22 Apr '19

22 Apr '19

siddjain(a)live.com wrote: > Full_Name: SIDDHARTH JAIN > Version: 2.4.45 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.226.196.10) > > > In some cases, OpenLDAP will modify the TLS certificate given to it before > sending it over to the client resulting in a certificate signature error. An > example of certificate it modifies is given below: OpenLDAP never touches the certificates you configure. If you're getting a corrupted certificate then there's either a bug in your storage/filesystem or in your SSL/TLS library. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#9014) OpenLDAP modifies user provided TLS certificate before sending it to client
by siddjain＠live.com 22 Apr '19

22 Apr '19

Full_Name: SIDDHARTH JAIN Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.226.196.10) In some cases, OpenLDAP will modify the TLS certificate given to it before sending it over to the client resulting in a certificate signature error. An example of certificate it modifies is given below: -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzANBgNVBAsTBmNsaWVudDAKBgNV BAsTA2puajEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMA0G A1UECxMGY2xpZW50MAoGA1UECxMDam5qMRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- The certificate returned to the client is however: -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzAKBgNVBAsTA2puajANBgNVBAsT BmNsaWVudDEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMAoG A1UECxMDam5qMA0GA1UECxMGY2xpZW50MRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- which is different. The setup on which we have tested this is using the osixia/openldap docker image https://github.com/osixia/docker-openldap. we are able to reproduce the error on both mac and ubuntu. The server is started using following command: docker run -p 636:636 \ --name $NAME \ --volume ${PWD}/data/slapd/database:/var/lib/ldap \ --volume ${PWD}/data/slapd/config:/etc/ldap/slapd.d \ --volume ${PWD}/data/slapd/certs:/container/service/slapd/assets/certs \ --env LDAP_TLS_VERIFY_CLIENT=never \ --env LDAP_TLS_ENFORCE=true \ --env HOSTNAME=jnj-ldap-server \ --env LDAP_DOMAIN="jnj.com" \ --env LDAP_ADMIN_PASSWORD="superman" \ --env LDAP_LOG_LEVEL:-1 \ --detach osixia/openldap:1.2.4 --loglevel debug --copy-service and below is result of running openssl root@6fc2ae248018:/usr/src/app# openssl s_client -state -nbio -connect jnj-ldap-server:636 -CAfile jnj-ca-chain.pem -showcerts CONNECTED(00000003) Turned on non blocking io SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:error in SSLv3/TLS write client hello write R BLOCK SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=2 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, CN = rca-jnj verify return:1 depth=1 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = client + OU = jnj, CN = rca-jnj-admin verify return:1 depth=0 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = jnj + OU = client, CN = jnj-ldap-server verify error:num=7:certificate signature failure verify return:1 depth=0 C = US, ST = WA, L = Bellevue, O = Johnson & Johnson, OU = jnj + OU = client, CN = jnj-ldap-server verify return:1 SSL_connect:SSLv3/TLS read server certificate SSL_connect:SSLv3/TLS read server key exchange SSL_connect:SSLv3/TLS read server done SSL_connect:SSLv3/TLS write client key exchange SSL_connect:SSLv3/TLS write change cipher spec SSL_connect:SSLv3/TLS write finished SSL_connect:error in SSLv3/TLS write finished read R BLOCK SSL_connect:SSLv3/TLS write finished SSL_connect:SSLv3/TLS read change cipher spec SSL_connect:SSLv3/TLS read finished read R BLOCK --- Certificate chain 0 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=jnj-ldap-server i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin -----BEGIN CERTIFICATE----- MIIDBzCCAq2gAwIBAgIULFEF1JLNT6p0mzk7sbK8vQM/R+0wCgYIKoZIzj0EAwIw fjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xGzAKBgNVBAsTA2puajANBgNVBAsT BmNsaWVudDEWMBQGA1UEAxMNcmNhLWpuai1hZG1pbjAeFw0xOTA0MTcxNjQ5MDBa Fw0yMDA0MTYxNjU0MDBaMIGAMQswCQYDVQQGEwJVUzELMAkGA1UECBMCV0ExETAP BgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYgSm9obnNvbjEbMAoG A1UECxMDam5qMA0GA1UECxMGY2xpZW50MRgwFgYDVQQDEw9qbmotbGRhcC1zZXJ2 ZXIwWTATBgcqhkjOPQIBBggqhkjOPQMBBwNCAATQ+ACOVmhx0kUAMqLdl6i+s2// 3CgJi7YIYs4wwgMipNK7+s70Wwyva7lv6r2rOrpGOtlifCw4zSXB1E+DxKXho4IB BDCCAQAwDgYDVR0PAQH/BAQDAgOoMB0GA1UdJQQWMBQGCCsGAQUFBwMBBggrBgEF BQcDAjAMBgNVHRMBAf8EAjAAMB0GA1UdDgQWBBT6olgSiuvK/c1P3/Gx+ljQL3yk FzAfBgNVHSMEGDAWgBTbr7PEPX6ZIN6APotjhLkd6hPeqDAaBgNVHREEEzARgg9q bmotbGRhcC1zZXJ2ZXIwZQYIKgMEBQYHCAEEWXsiYXR0cnMiOnsiaGYuQWZmaWxp YXRpb24iOiJqbmoiLCJoZi5FbnJvbGxtZW50SUQiOiJqbmotbGRhcC1zZXJ2ZXIi LCJoZi5UeXBlIjoiY2xpZW50In19MAoGCCqGSM49BAMCA0gAMEUCIQCN9saDTwXZ 4cefM27rUFT/1TqC3c7w8+NZNrJO3IYYFAIgHkGUYGABgiIEeQXyprd4AuLGhIZE mkhMI0uVeKWj1Jc= -----END CERTIFICATE----- 1 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj -----BEGIN CERTIFICATE----- MIICQTCCAeegAwIBAgIUBU9O3Wb3BDS8YuWRLYaKClbA9ZcwCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjMxOTAwWhcNMjQwMTMxMjMyNDAwWjB+MQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEbMAoGA1UECxMDam5qMA0GA1UECxMGY2xpZW50MRYwFAYDVQQDEw1y Y2Etam5qLWFkbWluMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEk4b8f5mWq+jf iMKQBVI8uU7btAF/LSSdXoOXYPW8JyJ23v5wtwRiQ/g4Al/6aIchvAC4QhJRUnz0 DMKuI7GCp6NmMGQwDgYDVR0PAQH/BAQDAgEGMBIGA1UdEwEB/wQIMAYBAf8CAQAw HQYDVR0OBBYEFNuvs8Q9fpkg3oA+i2OEuR3qE96oMB8GA1UdIwQYMBaAFBGV3Han Nf1T5i8fvDh239lt5W9DMAoGCCqGSM49BAMCA0gAMEUCIQD/4+AUOMBdofQEVsH2 2A6UGiJQvuplLEBA9in0cZTcCQIgcV5K+KCs3a5RNYUWdllakGx8c1f6ISrmk4an gjeXphQ= -----END CERTIFICATE----- 2 s:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj i:/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/CN=rca-jnj -----BEGIN CERTIFICATE----- MIIB/TCCAaOgAwIBAgIUSsxdq02aJCyaIHkIRxRdKvWYG9swCgYIKoZIzj0EAwIw WzELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAldBMREwDwYDVQQHEwhCZWxsZXZ1ZTEa MBgGA1UECgwRSm9obnNvbiAmIEpvaG5zb24xEDAOBgNVBAMTB3JjYS1qbmowHhcN MTkwMjAxMjExNDAwWhcNMzQwMTI4MjExNDAwWjBbMQswCQYDVQQGEwJVUzELMAkG A1UECBMCV0ExETAPBgNVBAcTCEJlbGxldnVlMRowGAYDVQQKDBFKb2huc29uICYg Sm9obnNvbjEQMA4GA1UEAxMHcmNhLWpuajBZMBMGByqGSM49AgEGCCqGSM49AwEH A0IABCF30Cn+O5sD/9n6d3IQQEGiceCTD7gG/5t4dHR4xmvm84HNgRngGKGF4fny 6BXkPSyDguP+L5zozdWDb8dWTQejRTBDMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMB Af8ECDAGAQH/AgEBMB0GA1UdDgQWBBQRldx2pzX9U+YvH7w4dt/ZbeVvQzAKBggq hkjOPQQDAgNIADBFAiEAkCQcOP+PmyVIMgr/cUsk04qH8lXYO4DqDuH1WSNvGfEC IBZQGRehpZ604FgkD0YqmiGRV/OzU99em0g3jkmWJbJY -----END CERTIFICATE----- --- Server certificate subject=/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=jnj-ldap-server issuer=/C=US/ST=WA/L=Bellevue/O=Johnson & Johnson/OU=jnj/OU=client/CN=rca-jnj-admin --- No client certificate CA names sent Peer signing digest: SHA512 Server Temp Key: ECDH, P-256, 256 bits --- SSL handshake has read 2202 bytes and written 302 bytes Verification error: certificate signature failure --- New, TLSv1.2, Cipher is ECDHE-ECDSA-AES256-GCM-SHA384 Server public key is 256 bit Secure Renegotiation IS supported Compression: NONE Expansion: NONE No ALPN negotiated SSL-Session: Protocol : TLSv1.2 Cipher : ECDHE-ECDSA-AES256-GCM-SHA384 Session-ID: CAA7D5C4B5733C027877F5BC255EEA192B70E5D6125BC359B19CDDD3708BF857 Session-ID-ctx: Master-Key: 94727E3BE5361CCC34D02DDD797F62C7875A96283A1EB12FBD584749E36E804DE7BD402C81CDFC0F9F3DF0487BE38399 PSK identity: None PSK identity hint: None SRP username: None Start Time: 1555951187 Timeout : 7200 (sec) Verify return code: 7 (certificate signature failure) Extended master secret: yes --- there is a certificate signature failure since the certificate returned to the client is different from the certificate provided to the server.

1 0

(ITS#9012) MDB maxsize gets truncated to 32-bit on Windows
by quanah＠openldap.org 21 Apr '19

21 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4 OS: Windows URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) When using a 64-bit build of OpenLDAP on windows with LMDB, you cannot have a database larger than 3GB (Any value over 3GB gets truncated to 3GB, at least until you overflow the 32-bit int value space).

1 0

(ITS#9011) add mdb_txn_flags()
by christopher＠gmerlin.de 20 Apr '19

20 Apr '19

Full_Name: Christopher Zimmermann Version: lmdb 0.9.23 OS: OpenBSD URL: Submission from: (NULL) (85.212.134.155) Hello, I'm working on a language binding of lmdb for OCaml. While doing so I missed a functin with with to check whether a transaction is read-only. To implement the functionality I propose the following change. The attached patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Christopher Zimmermann <christopher(a)gmerlin.de>. I have not assigned rights and/or interest in this work to any party. I, Christopher Zimmermann, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. >From 2e573257a15edb0aebef3d522c262fa75c676f84 Mon Sep 17 00:00:00 2001 From: Christopher Zimmermann <madroach(a)gmerlin.de> Date: Sat, 20 Apr 2019 23:06:51 +0200 Subject: [PATCH] Add mdb_txn_flags() --- libraries/liblmdb/lmdb.h | 8 ++++++++ libraries/liblmdb/mdb.c | 7 +++++++ 2 files changed, 15 insertions(+) diff --git libraries/liblmdb/lmdb.h libraries/liblmdb/lmdb.h index 50ee37f..46ae389 100644 --- libraries/liblmdb/lmdb.h +++ libraries/liblmdb/lmdb.h @@ -989,6 +989,14 @@ MDB_env *mdb_txn_env(MDB_txn *txn); */ size_t mdb_txn_id(MDB_txn *txn); + /** @brief Retrieve the transaction's flags + * + * @param[in] txn A transaction handle returned by #mdb_txn_begin() + * @param[out] flags Address where the flags will be returned. + * @return A non-zero error value on failure and 0 on success. + */ +int mdb_txn_flags(MDB_txn *txn, unsigned int *flags); + /** @brief Commit all the operations of a transaction into the database. * * The transaction handle is freed. It and its cursors must not be used diff --git libraries/liblmdb/mdb.c libraries/liblmdb/mdb.c index 692feaa..fdf7618 100644 --- libraries/liblmdb/mdb.c +++ libraries/liblmdb/mdb.c @@ -2934,6 +2934,13 @@ mdb_txn_id(MDB_txn *txn) return txn->mt_txnid; } +int mdb_txn_flags(MDB_txn *txn, unsigned int *flags) +{ + if(!txn) return EINVAL; + *flags = txn->mt_flags & MDB_RDONLY; + return MDB_SUCCESS; +} + /** Export or close DBI handles opened in this txn. */ static void mdb_dbis_update(MDB_txn *txn, int keep) -- 2.20.1

1 0

Re: (ITS#7755) not replicated nodes after recovery
by quanah＠symas.com 19 Apr '19

19 Apr '19

--On Wednesday, November 27, 2013 5:26 AM +0000 dmitrii.fonariuk(a)gmail.com wrote: > Full_Name: Dmitrii Fonariuk > > I can conclude that the back is not replicated that DN, entryCSN value > that matches the value serverID. > > This is a bug or a feature? Hello, This would be a bug. However, it's most likely fixed since the 2.4.38 release, as there have been numerous replication related fixes since that time. If you can reproduce this issue with the current OpenLDAP release, please let us know. I apologize for the length in time in responding to this report. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#9010) 2.5: Remove back-bdb and back-hdb
by quanah＠openldap.org 19 Apr '19

19 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.5 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) For 2.5, remove back-bdb and back-hdb from the OpenLDAP distribution. This depends on ITS#9009 in the long term, so that large DBs can be used in a 32-bit environment with LMDB. The work to remove bdb/hdb can start now, however.

1 0

(ITS#9009) 2.5: Switch to LMDB v1.0
by quanah＠openldap.org 19 Apr '19

19 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.5 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) For the OpenLDAP 2.5 release, we need to switch to using liblmdb v1.0 for the newer features, including MDB_VL32 support.

1 0

Re: (ITS#8780) Plug a socket leak in ldap_new_connection made by unsuccessful connection attempts
by quanah＠symas.com 19 Apr '19

19 Apr '19

--On Thursday, April 18, 2019 4:59 PM +0000 michael(a)stroeder.com wrote: > I considered contacting current SUSE maintainers of package openldap2. > > In preparation to that I tried to find out which bug caused this patch > to be developed. > > AFAIK the patch is not applied to the package anymore: > https://build.opensuse.org/package/show/network:ldap/openldap2 > > And I have no reference to further information. > > To OpenLDAP devs: > Does Howard's patch still make sense? > Is it worth to dig into SUSE's bugzilla to find out more? Hi Michael, Thanks for the updated information. It sounds like this patch is no longer necessary, so I'm going to close out the ITS. --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#8998) ldapi:// with SASL_NOCANON -> Local error (-2)
by hyc＠symas.com 18 Apr '19

18 Apr '19

michael(a)stroeder.com wrote: > On 4/18/19 3:36 AM, Quanah Gibson-Mount wrote: >> Does the patch referenced in ITS#7585 fix this for you?=C3=82=C2=A0 Be= en waiting=20 >> for years for RedHat to update with the IPR. ;) >=20 > Disclaimer: I'm not a C programmer. >=20 > Maybe it's me but AFAICS even if nocanon evaluates to True there's=20 > always a call into gethostname(). Does that make sense? >=20 > Ciao, Michael. I reproduced your issue, and applying the ITS#7585 patch fixes it for me.= Closing this as a dup of #7585. --=20 -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2019