- openldap-bugs - openldap.org

[Issue 9564] New: Race condition with freeing the spilled pages from transaction
by openldap-its＠openldap.org 27 May '21

27 May '21

https://bugs.openldap.org/show_bug.cgi?id=9564 Issue ID: 9564 Summary: Race condition with freeing the spilled pages from transaction Product: LMDB Version: 0.9.29 Hardware: Other OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- Created attachment 825 --> https://bugs.openldap.org/attachment.cgi?id=825&action=edit Free the spilled pages and dirty overflows before unlocking the write mutex The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write transaction's mutex is unlocked (in mdb.master3). This can result in a race condition where a second transaction can start and subsequently assign a new mt_spill_pgs list to the transaction structure that it reuses. If this occurs after the first transaction unlocks the mutex, but before it performs the free operation on mt_spill_pgs, then the first transaction will end up calling a free on the same spilled page list as the second transaction, resulting in a double free (and crash). It would seem to be an extremely unlikely scenario to actually happen, since the free call is literally the next operation after the mutex is unlocked, and the second transaction would need to make it all the way to the point of saving the freelist before a page spill list is likely to be allocated. Consequently, this probably has rarely happened. However, one of our users (see https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has noticed this occurring, and it seems that it may be particularly likely to happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how the threads are more likely to yield execution after a mutex unlock, I am not sure. I was able to reproduce the issue by intentionally manipulating the timing (sleeping before the free) to verify that the race condition is technically feasible, and apparently this can happen "in the wild" on MacOS, at least with an M1. It is also worth noting that this is due to (or a regression from) the fix for ITS#9155 (https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277) where the free call was moved outside the conditional (for having a parent) that had previously never been executed after the mutex is unlocked, but now is called after the unlock. Anyway, the solution is relatively simple, the free call simply has to be moved above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should be handled the same. This could alternately be solved by saving the reference to these lists before unlocking, and freeing after unlocking, which would slightly decrease the amount of processing within the mutex guarded code. Let me know if you prefer a patch that does that. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9563] New: OpenLDAP enable TLS1.3
by openldap-its＠openldap.org 26 May '21

26 May '21

https://bugs.openldap.org/show_bug.cgi?id=9563 Issue ID: 9563 Summary: OpenLDAP enable TLS1.3 Product: OpenLDAP Version: 2.4.45 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: santhu227(a)gmail.com Target Milestone: --- How we can enable TLS1.3 on OopenLDAP for ubuntu 18.04.5 LTS. Package details : OS PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" OpenSSL 1.1.1g 21 Apr 2020. grep -R olcTLS /etc/ldap/slapd.d/ /etc/ldap/slapd.d/cn=config.ldif:olcTLSCRLCheck: none /etc/ldap/slapd.d/cn=config.ldif:olcTLSProtocolMin: 3.4 /etc/ldap/slapd.d/cn=config.ldif:olcTLSCipherSuite: NORMAL /etc/ldap/slapd.d/cn=config.ldif:olcTLSVerifyClient: try /etc/ldap/slapd.d/cn=config.ldif:olcTLSCACertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_server_new_13.key /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt dpkg -s slapd | grep Version Version: 2.4.45+dfsg-1ubuntu1.10 Is there any possibility to enable TLS1.3 on slapd service(OpenLDAP server) for above configuration. If need to upgrade any package will it be possible to upgrade or update on Ubuntu 18.04.5. openssl client output where openssl is not able to connecte with TLS1.3. Same will list ciphers for TLS1.2 openssl s_client -connect <host>:636 -tls1_3 CONNECTED(00000003) write:errno=0 --- no peer certificate available --- No client certificate CA names sent --- SSL handshake has read 0 bytes and written 215 bytes Verification: OK --- New, (NONE), Cipher is (NONE) Secure Renegotiation IS NOT supported Compression: NONE Expansion: NONE No ALPN negotiated Early data was not sent Verify return code: 0 (ok) --- -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9562] New: Unable to setup TLS1.3
by openldap-its＠openldap.org 26 May '21

26 May '21

https://bugs.openldap.org/show_bug.cgi?id=9562 Issue ID: 9562 Summary: Unable to setup TLS1.3 Product: OpenLDAP Version: 2.4.45 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: santhu227(a)gmail.com Target Milestone: --- How we can enable TLS1.3 on OopenLDAP for ubuntu 18.04.5 LTS. Package details : OS PRETTY_NAME="Ubuntu 18.04.5 LTS" VERSION_ID="18.04" OpenSSL 1.1.1g 21 Apr 2020. grep -R olcTLS /etc/ldap/slapd.d/ /etc/ldap/slapd.d/cn=config.ldif:olcTLSCRLCheck: none /etc/ldap/slapd.d/cn=config.ldif:olcTLSProtocolMin: 3.3 /etc/ldap/slapd.d/cn=config.ldif:olcTLSCipherSuite: NORMAL /etc/ldap/slapd.d/cn=config.ldif:olcTLSVerifyClient: try /etc/ldap/slapd.d/cn=config.ldif:olcTLSCACertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateKeyFile: /etc/ldap/sasl2/ldap_server_new_13.key /etc/ldap/slapd.d/cn=config.ldif:olcTLSCertificateFile: /etc/ldap/sasl2/ldap_server_new_13.crt dpkg -s slapd | grep Version Version: 2.4.45+dfsg-1ubuntu1.10 Is there any possibility to enable TLS1.3 on slapd service(OpenLDAP server) for above configuration. If need to upgrade any package will it be possible to upgrade or update on Ubuntu 18.04.5. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9560] New: Dead images in documentation
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9560 Issue ID: 9560 Summary: Dead images in documentation Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: shea.ramage(a)gmail.com Target Milestone: --- Created attachment 823 --> https://bugs.openldap.org/attachment.cgi?id=823&action=edit Screenshot of broken images Documentation release 2.5 (https://www.openldap.org/doc/admin25) contains several dead image links. One example (Figure 3.1) https://www.openldap.org/doc/admin25/config_local.png results in a 404 not found error, however changing the '5' in the URL to a '4' loads an image correctly. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9558] New: unable to add DB DIT , getting value #0 invalid per syntax error
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9558 Issue ID: 9558 Summary: unable to add DB DIT , getting value #0 invalid per syntax error Product: OpenLDAP Version: 2.4.50 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: govind.rathod(a)hpe.com Target Milestone: --- unable to add DB DIT , getting value #0 invalid per syntax error command used : ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif below is the content of "create_sns_db.ldif" file dn: olcDatabase=mdb,cn=config objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 1073741824 olcSuffix: dc=smartsan olcDbDirectory: /usr/local/var/openldap-data/sns_db olcRootDN: cn=admin,dc=smartsan olcRootPW: secret2 olcDbIndex: objectClass eq below is the debug output for the ldapadd command used: #ldapadd -x -D 'cn=config' -w secret -f create_sns_db.ldif -d 255 ldap_create ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP localhost:389 ldap_new_socket: 4 ldap_prepare_socket: 4 ldap_connect_to_host: Trying ::1 389 ldap_pvt_connect: fd: 4 tm: -1 async: 0 attempting to connect: connect success ldap_open_defconn: successful ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f1aa9d18010 ptr=0x7f1aa9d18010 end=0x7f1aa9d1802d len=29 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ber_scanf fmt ({i) ber: ber_dump: buf=0x7f1aa9d18010 ptr=0x7f1aa9d18015 end=0x7f1aa9d1802d len=24 0000: 60 16 02 01 03 04 09 63 6e 3d 63 6f 6e 66 69 67 `......cn=config 0010: 80 06 73 65 63 72 65 74 ..secret ber_flush2: 29 bytes to sd 4 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ldap_write: want=29, written=29 0000: 30 1b 02 01 01 60 16 02 01 03 04 09 63 6e 3d 63 0....`......cn=c 0010: 6f 6e 66 69 67 80 06 73 65 63 72 65 74 onfig..secret ldap_result ld 0x7f1aaa121dc0 msgid 1 wait4msg ld 0x7f1aaa121dc0 msgid 1 (infinite timeout) wait4msg continue ld 0x7f1aaa121dc0 msgid 1 all 1 ** ld 0x7f1aaa121dc0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue May 25 05:42:41 2021 ** ld 0x7f1aaa121dc0 Outstanding Requests: * msgid 1, origid 1, status InProgress outstanding referrals 0, parent count 0 ld 0x7f1aaa121dc0 request count 1 (abandoned 0) ** ld 0x7f1aaa121dc0 Response Queue: Empty ld 0x7f1aaa121dc0 response count 0 ldap_chkResponseList ld 0x7f1aaa121dc0 msgid 1 all 1 ldap_chkResponseList returns ld 0x7f1aaa121dc0 NULL ldap_int_select read1msg: ld 0x7f1aaa121dc0 msgid 1 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 0c 02 01 01 61 07 0a 0....a.. ldap_read: want=6, got=6 0000: 01 00 04 00 04 00 ...... ber_get_next: tag 0x30 len 12 contents: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b10 end=0x7f1aaa048b1c len=12 0000: 02 01 01 61 07 0a 01 00 04 00 04 00 ...a........ read1msg: ld 0x7f1aaa121dc0 msgid 1 message type bind ber_scanf fmt ({eAA) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b13 end=0x7f1aaa048b1c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ read1msg: ld 0x7f1aaa121dc0 0 new referrals read1msg: mark request completed, ld 0x7f1aaa121dc0 msgid 1 request done: ld 0x7f1aaa121dc0 msgid 1 res_errno: 0, res_error: <>, res_matched: <> ldap_free_request (origid 1, msgid 1) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b13 end=0x7f1aaa048b1c len=9 0000: 61 07 0a 01 00 04 00 04 00 a........ ber_scanf fmt (}) ber: ber_dump: buf=0x7f1aaa048b10 ptr=0x7f1aaa048b1c end=0x7f1aaa048b1c len=0 ldap_msgfree adding new entry "olcDatabase=mdb,cn=config" ldap_add_ext ldap_send_initial_request ldap_send_server_request ber_scanf fmt ({it) ber: ber_dump: buf=0x7f1aa9d18020 ptr=0x7f1aa9d18020 end=0x7f1aa9d18148 len=296 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ber_scanf fmt ({) ber: ber_dump: buf=0x7f1aa9d18020 ptr=0x7f1aa9d18027 end=0x7f1aa9d18148 len=289 0000: 68 82 01 1d 04 19 6f 6c 63 44 61 74 61 62 61 73 h.....olcDatabas 0010: 65 3d 6d 64 62 2c 63 6e 3d 63 6f 6e 66 69 67 30 e=mdb,cn=config0 0020: 81 ff 30 1d 04 0b 6f 62 6a 65 63 74 43 6c 61 73 ..0...objectClas 0030: 73 31 0e 04 0c 6f 6c 63 4d 64 62 43 6f 6e 66 69 s1...olcMdbConfi 0040: 67 30 14 04 0b 6f 6c 63 44 61 74 61 62 61 73 65 g0...olcDatabase 0050: 31 05 04 03 6d 64 62 30 1c 04 0c 6f 6c 63 44 62 1...mdb0...olcDb 0060: 4d 61 78 53 69 7a 65 31 0c 04 0a 31 30 37 33 37 MaxSize1...10737 0070: 34 31 38 32 34 30 1a 04 09 6f 6c 63 53 75 66 66 418240...olcSuff 0080: 69 78 31 0d 04 0b 64 63 3d 73 6d 61 72 74 73 61 ix1...dc=smartsa 0090: 6e 30 31 04 0e 6f 6c 63 44 62 44 69 72 65 63 74 n01..olcDbDirect 00a0: 6f 72 79 31 1f 04 1d 2f 76 61 72 2f 6c 69 62 2f ory1.../var/lib/ 00b0: 6f 70 65 6e 6c 64 61 70 2d 64 61 74 61 2f 73 6e openldap-data/sn 00c0: 73 5f 64 62 30 23 04 09 6f 6c 63 52 6f 6f 74 44 s_db0#..olcRootD 00d0: 4e 31 16 04 14 63 6e 3d 61 64 6d 69 6e 2c 64 63 N1...cn=admin,dc 00e0: 3d 73 6d 61 72 74 73 61 6e 30 16 04 09 6f 6c 63 =smartsan0...olc 00f0: 52 6f 6f 74 50 57 31 09 04 07 73 65 63 72 65 74 RootPW1...secret 0100: 32 30 1e 04 0a 6f 6c 63 44 62 49 6e 64 65 78 31 20...olcDbIndex1 0110: 10 04 0e 6f 62 6a 65 63 74 43 6c 61 73 73 20 65 ...objectClass e 0120: 71 q ber_flush2: 296 bytes to sd 4 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ldap_write: want=296, written=296 0000: 30 82 01 24 02 01 02 68 82 01 1d 04 19 6f 6c 63 0..$...h.....olc 0010: 44 61 74 61 62 61 73 65 3d 6d 64 62 2c 63 6e 3d Database=mdb,cn= 0020: 63 6f 6e 66 69 67 30 81 ff 30 1d 04 0b 6f 62 6a config0..0...obj 0030: 65 63 74 43 6c 61 73 73 31 0e 04 0c 6f 6c 63 4d ectClass1...olcM 0040: 64 62 43 6f 6e 66 69 67 30 14 04 0b 6f 6c 63 44 dbConfig0...olcD 0050: 61 74 61 62 61 73 65 31 05 04 03 6d 64 62 30 1c atabase1...mdb0. 0060: 04 0c 6f 6c 63 44 62 4d 61 78 53 69 7a 65 31 0c ..olcDbMaxSize1. 0070: 04 0a 31 30 37 33 37 34 31 38 32 34 30 1a 04 09 ..10737418240... 0080: 6f 6c 63 53 75 66 66 69 78 31 0d 04 0b 64 63 3d olcSuffix1...dc= 0090: 73 6d 61 72 74 73 61 6e 30 31 04 0e 6f 6c 63 44 smartsan01..olcD 00a0: 62 44 69 72 65 63 74 6f 72 79 31 1f 04 1d 2f 76 bDirectory1.../v 00b0: 61 72 2f 6c 69 62 2f 6f 70 65 6e 6c 64 61 70 2d ar/lib/openldap- 00c0: 64 61 74 61 2f 73 6e 73 5f 64 62 30 23 04 09 6f data/sns_db0#..o 00d0: 6c 63 52 6f 6f 74 44 4e 31 16 04 14 63 6e 3d 61 lcRootDN1...cn=a 00e0: 64 6d 69 6e 2c 64 63 3d 73 6d 61 72 74 73 61 6e dmin,dc=smartsan 00f0: 30 16 04 09 6f 6c 63 52 6f 6f 74 50 57 31 09 04 0...olcRootPW1.. 0100: 07 73 65 63 72 65 74 32 30 1e 04 0a 6f 6c 63 44 .secret20...olcD 0110: 62 49 6e 64 65 78 31 10 04 0e 6f 62 6a 65 63 74 bIndex1...object 0120: 43 6c 61 73 73 20 65 71 Class eq ldap_result ld 0x7f1aaa121dc0 msgid 2 wait4msg ld 0x7f1aaa121dc0 msgid 2 (timeout 100000 usec) wait4msg continue ld 0x7f1aaa121dc0 msgid 2 all 1 ** ld 0x7f1aaa121dc0 Connections: * host: localhost port: 389 (default) refcnt: 2 status: Connected last used: Tue May 25 05:42:41 2021 ** ld 0x7f1aaa121dc0 Outstanding Requests: * msgid 2, origid 2, status InProgress outstanding referrals 0, parent count 0 ld 0x7f1aaa121dc0 request count 1 (abandoned 0) ** ld 0x7f1aaa121dc0 Response Queue: Empty ld 0x7f1aaa121dc0 response count 0 ldap_chkResponseList ld 0x7f1aaa121dc0 msgid 2 all 1 ldap_chkResponseList returns ld 0x7f1aaa121dc0 NULL ldap_int_select read1msg: ld 0x7f1aaa121dc0 msgid 2 all 1 ber_get_next ldap_read: want=8, got=8 0000: 30 34 02 01 02 69 2f 0a 04...i/. ldap_read: want=46, got=46 0000: 01 15 04 00 04 28 6f 62 6a 65 63 74 43 6c 61 73 .....(objectClas 0010: 73 3a 20 76 61 6c 75 65 20 23 30 20 69 6e 76 61 s: value #0 inva 0020: 6c 69 64 20 70 65 72 20 73 79 6e 74 61 78 lid per syntax ber_get_next: tag 0x30 len 52 contents: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb0 end=0x565118724fe4 len=52 0000: 02 01 02 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 ...i/......(obje 0010: 63 74 43 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 ctClass: value # 0020: 30 20 69 6e 76 61 6c 69 64 20 70 65 72 20 73 79 0 invalid per sy 0030: 6e 74 61 78 ntax read1msg: ld 0x7f1aaa121dc0 msgid 2 message type add ber_scanf fmt ({eAA) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb3 end=0x565118724fe4 len=49 0000: 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 63 74 43 i/......(objectC 0010: 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 30 20 69 lass: value #0 i 0020: 6e 76 61 6c 69 64 20 70 65 72 20 73 79 6e 74 61 nvalid per synta 0030: 78 x read1msg: ld 0x7f1aaa121dc0 0 new referrals read1msg: mark request completed, ld 0x7f1aaa121dc0 msgid 2 request done: ld 0x7f1aaa121dc0 msgid 2 res_errno: 21, res_error: <objectClass: value #0 invalid per syntax>, res_matched: <> ldap_free_request (origid 2, msgid 2) ldap_parse_result ber_scanf fmt ({iAA) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fb3 end=0x565118724fe4 len=49 0000: 69 2f 0a 01 15 04 00 04 28 6f 62 6a 65 63 74 43 i/......(objectC 0010: 6c 61 73 73 3a 20 76 61 6c 75 65 20 23 30 20 69 lass: value #0 i 0020: 6e 76 61 6c 69 64 20 70 65 72 20 73 79 6e 74 61 nvalid per synta 0030: 78 x ber_scanf fmt (}) ber: ber_dump: buf=0x565118724fb0 ptr=0x565118724fe4 end=0x565118724fe4 len=0 ldap_msgfree ldap_err2string ldap_add: Invalid syntax (21) additional info: objectClass: value #0 invalid per syntax ldap_free_connection 1 1 ldap_send_unbind ber_flush2: 7 bytes to sd 4 0000: 30 05 02 01 03 42 00 0....B. ldap_write: want=7, written=7 0000: 30 05 02 01 03 42 00 0....B. ldap_free_connection: actually freed Note: i have manually typed the contents of the ldif file to make sure no extra characters are there. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9539] New: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0)
by openldap-its＠openldap.org 25 May '21

25 May '21

https://bugs.openldap.org/show_bug.cgi?id=9539 Issue ID: 9539 Summary: ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) Product: LMDB Version: 0.9.28 Hardware: x86_64 OS: Windows Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- On Windows, with the attached program and the commands below, I am getting ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(env, 0) on the latest 0.9.28 release. The program works as expected on mdb.master. git clone https://github.com/LMDB/lmdb.git cd lmdb git reset --hard LMDB_0.9.28 cd .. call "c:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\VC\Auxiliary\Build\vcvars64.bat" cl -Femain.exe -Ilmdb/libraries/liblmdb main.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib cl -Feloop.exe -Ilmdb/libraries/liblmdb loop.c lmdb/libraries/liblmdb/mdb.c lmdb/libraries/liblmdb/midl.c Advapi32.lib .\main.exe Example output: Loop 300000 400000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 500000 600000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 200000 300000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 400000 500000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 600000 700000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 100000 200000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 700000 800000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 900000 1000000 starting. Got ERROR_USER_MAPPED_FILE from mdb_env_set_mapsize(0). Loop 800000 900000 starting. Loop 800000 900000 done. Non-zero 0 exit code 1. Non-zero 1 exit code 1. Non-zero 2 exit code 1. Non-zero 3 exit code 1. Non-zero 4 exit code 1. Non-zero 5 exit code 1. Non-zero 6 exit code 1. Non-zero 8 exit code 1. All done. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 21 May '21

21 May '21

https://bugs.openldap.org/show_bug.cgi?id=8882 --- Comment #10 from Matthew Hardin <mhardin(a)symas.com> --- It appears that the source code for the module is no longer on the FTP server. Would someone from daasi please upload it and mark the correct URL in the comment? Thanks, -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 20 May '21

20 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c216ef53 by Ondřej Kuzník at 2021-05-15T10:01:18+01:00 ITS#6467 Reset avl root after releasing the tree • 5943a334 by Ondřej Kuzník at 2021-05-15T10:01:51+01:00 ITS#6467 Adjust log message -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 20 May '21

20 May '21

https://bugs.openldap.org/show_bug.cgi?id=7335 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ | Target Milestone|2.5.5 |2.6.0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 20 May '21

20 May '21

https://bugs.openldap.org/show_bug.cgi?id=8882 --- Comment #9 from tamim.ziai(a)daasi.de <tamim.ziai(a)daasi.de> --- The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by DAASI International. DAASI International has not assigned rights and/or interest in this work to any party. I, Tamim Ziai is authorized by DAASI International to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2019 DAASI International Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8679] Update release download page
by openldap-its＠openldap.org 19 May '21

19 May '21

https://bugs.openldap.org/show_bug.cgi?id=8679 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8679] Update release download page
by openldap-its＠openldap.org 19 May '21

19 May '21

https://bugs.openldap.org/show_bug.cgi?id=8679 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9487] New: Committed changes not saved to accesslog during shutdown
by openldap-its＠openldap.org 17 May '21

17 May '21

https://bugs.openldap.org/show_bug.cgi?id=9487 Issue ID: 9487 Summary: Committed changes not saved to accesslog during shutdown Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If there is inbound write traffic when slapd is asked to shut down, some of these operations get written to the main database but accesslog might be prevented from ADDing the log entry into its own database (presumably since slapd is shutting down already). This prevents these updates from being replicated in a deltasync scenario and silently desync. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9553] New: Segfault in mdb_txn_abort handler caused by uninitialized pointer in mdb_reader_flush
by openldap-its＠openldap.org 17 May '21

17 May '21

https://bugs.openldap.org/show_bug.cgi?id=9553 Issue ID: 9553 Summary: Segfault in mdb_txn_abort handler caused by uninitialized pointer in mdb_reader_flush Product: OpenLDAP Version: 2.4.58 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: jrddunbr(a)amazon.com Target Milestone: --- This is for OpenLDAP 2.4.58, git commit 350ede08564ab14a45884c6f7c32419d98a75468 best I can tell. I have located an issue in mdb_reader_flush where it appears that an uninitialized pointer causes segfaults when threading is disabled. In the following function: https://git.openldap.org/openldap/openldap/-/blob/350ede08564ab14a45884c6f7… ``` void mdb_reader_flush( MDB_env *env ) { void *data; void *ctx = ldap_pvt_thread_pool_context(); if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { ldap_pvt_thread_pool_setkey( ctx, env, NULL, 0, NULL, NULL ); mdb_reader_free( env, data ); } } ``` the `void *data;` gets random values and is not initialized to NULL; when there is no thread pool the functions after it return without doing anything, and that pointer is passed down into mdb_reader_free, which passes down to mdb_txn_abort, where it is (recursively) de-referenced until the pointer is NULL. This causes a segfault, as that condition is not reached before it tries reading invalid memory addresses. The fix appears to be to make the following modification: Change `void *data;` to `void *data = NULL;`. I don't actually know much about the internals of this application, so I wanted to make sure that this is the correct solution before making a pull request for it. Apologies if my C terminology is not up to snuff; this is not my forte. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 May '21

14 May '21

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|hyc(a)openldap.org |ondra(a)mistotebe.net -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 May '21

14 May '21

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ | Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 363f1056 by Ondřej Kuzník at 2021-05-14T08:18:05+01:00 ITS#8820 Document ldap_get_attribute_ber() -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9540] New: userSMIMECertificate needs to be binary
by openldap-its＠openldap.org 12 May '21

12 May '21

https://bugs.openldap.org/show_bug.cgi?id=9540 Issue ID: 9540 Summary: userSMIMECertificate needs to be binary Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: openldap.ms(a)savignano.net Target Milestone: --- OpenLDAP uses inetOrgPerson.schema with the following note on userSMIMECertificate attribute: # userSMIMECertificate # [...] Values for # this attribute are to be stored and requested in binary form, as # 'userSMIMECertificate;binary'. [...] but a line is added saying specifically ## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary This seems to make no sense. According to RFC 2798 which define inetOrgPerson and the useSMIMECertificate (first comment is quoted from there), this attribute must be stored and requested as userSMIMECertificate;binary. OpenLDAP does not do so. I don't understand the explanation "as syntax is binary". This leads to problems with clients following RFC 2798 and requesting the attribute as userSMIMECertificate;binary because OpenLDAP does not send userSMIMECertificate instead, but sends nothing at all (as if attribute would not exist). I think this is a bug. OpenLDAP does not follow RFC 2798 and this causes compatibility problems. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 12 May '21

12 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9552 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 11 May '21

11 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • efb84b3e by Ondřej Kuzník at 2021-05-11T18:19:22+00:00 ITS#6467 Handle syncrepl searches with base of "" -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=8747 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.1 |2.5.5 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=8747 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 2c1bb42f by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Do not observe an epoch while calling dispose_cb • 4f499755 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Avoid epoch recursion in connection_write_cb • a186fd70 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Do not continue reading if connection is dying • 3802fa92 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Fix lloadd builds --without-tls • 1cb65102 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Keep an explicit backend pointer • 8e4d7ffe by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Remove c_private from LloadConnection • cba03e49 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Protect shutdown code while workers are still alive -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/328 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.5 Status|CONFIRMED |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|VERIFIED |CONFIRMED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9535] New: test078 fails on MacOS due to output formatting
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9535 Issue ID: 9535 Summary: test078 fails on MacOS due to output formatting Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- On MacOSX the output of the "wc" command is right-justified. This causes a mismatch against the reference data. God only knows why... -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs