- openldap-bugs - openldap.org

[Issue 9995] New: Potential memory leak in clients/tools/ldapdelete.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9995 Issue ID: 9995 Summary: Potential memory leak in clients/tools/ldapdelete.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in ldapdelete.c line 384.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10032] New: at_add returns a free'd pointer on error
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10032 Issue ID: 10032 Summary: at_add returns a free'd pointer on error Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- When an invalid schema is provided (e.g. the current ./servers/slapd/schema/msuser.schema of memberof/dynlist is loaded already), at_add() hits error handling and frees at->at_oid, but that string is being returned in *err. A fix is coming. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9989] New: «make clean» shall not delete libraries/libldap/ldap.pc and libraries/liblber/lber.pc
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9989 Issue ID: 9989 Summary: «make clean» shall not delete libraries/libldap/ldap.pc and libraries/liblber/lber.pc Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- «./configure» and «./config.status» do create ./libraries/libldap/ldap.pc, ./libraries/liblber/lber.pc, while «make clean» deletes both .pc files. «make install» fails, if ./libraries/libldap/ldap.pc or ./libraries/liblber/lber.pc are missing. «./configure && make clean && make depend && make install» is a valid workflow for many other (autoconf/automake based) projects. ./libraries/libldap/ldap.pc and ./libraries/liblber/lber.pc shall be deleted by «make distclean», and kept by «make clean». See also https://www.gnu.org/prep/standards/html_node/Standard-Targets.html for the idea behind «make clean» vs «make distclean». -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10028] New: crash with pwdMinDelay
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10028 Issue ID: 10028 Summary: crash with pwdMinDelay Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- slapd crash when using pwdMinDelay of ppolicy. The cause is that slap_timestamp() writes to undefined area. It has already been fixed. backtrace: ``` (gdb) bt #0 0x00007f2c70bdbaff in raise () from /lib64/libc.so.6 #1 0x00007f2c70baeea5 in abort () from /lib64/libc.so.6 #2 0x00007f2c70baed79 in __assert_fail_base.cold.0 () from /lib64/libc.so.6 #3 0x00007f2c70bd4456 in __assert_fail () from /lib64/libc.so.6 #4 0x0000000000499fdf in entry_schema_check (op=<optimized out>, op@entry=0x7f2c2a9a9ff0, e=<optimized out>, e@entry=0x7f2c20001d30, oldattrs=<optimized out>, oldattrs@entry=0x7f2c20001d30, manage=0, add=add@entry=0, socp=socp@entry=0x7f2c2a9a99d8, text=0x7f2c2a9a9f30, textbuf=0x7f2c2a9a9b40 "", textlen=256) at ../../../servers/slapd/schema_check.c:89 #5 0x00000000004f5dc1 in mdb_modify_internal (op=<optimized out>, op@entry=0x7f2c2a9a9ff0, tid=tid@entry=0x11dc8c0, modlist=<optimized out>, e=<optimized out>, e@entry=0x7f2c2a9a9ac0, text=text@entry=0x7f2c2a9a9f30, textbuf=textbuf@entry=0x7f2c2a9a9b40 "", textlen=256) at ../../../../servers/slapd/back-mdb/modify.c:419 #6 0x00000000004f6cfa in mdb_modify (op=0x7f2c2a9a9ff0, rs=0x7f2c2a9a9f10) at ../../../../servers/slapd/back-mdb/modify.c:714 #7 0x00000000004d5833 in overlay_op_walk (op=0x7f2c2a9a9ff0, rs=0x7f2c2a9a9f10, which=<optimized out>, oi=0xfc1a00, on=0x0) at ../../../servers/slapd/backover.c:706 #8 over_op_func (op=0x7f2c2a9a9ff0, rs=0x7f2c2a9a9f10, which=op_modify) at ../../../servers/slapd/backover.c:766 #9 0x00007f2c6be56a95 in ppolicy_bind_response (op=<optimized out>, rs=0x7f2c2a9aa730) at ../../../../servers/slapd/overlays/ppolicy.c:1827 #10 0x0000000000475878 in slap_response_play (op=0x7f2c201039a0, rs=0x7f2c2a9aa730) at ../../../servers/slapd/result.c:567 #11 send_ldap_response (op=op@entry=0x7f2c201039a0, rs=rs@entry=0x7f2c2a9aa730) at ../../../servers/slapd/result.c:642 #12 0x0000000000475f2c in slap_send_ldap_result (op=0x7f2c201039a0, rs=0x7f2c2a9aa730) at ../../../servers/slapd/result.c:918 #13 0x000000000052b6cf in mdb_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730) at ../../../../servers/slapd/back-mdb/bind.c:148 #14 0x00000000004d5833 in overlay_op_walk (op=0x7f2c201039a0, rs=0x7f2c2a9aa730, which=<optimized out>, oi=0xfc1a00, on=0x0) at ../../../servers/slapd/backover.c:706 #15 over_op_func (op=0x7f2c201039a0, rs=0x7f2c2a9aa730, which=op_bind) at ../../../servers/slapd/backover.c:766 #16 0x00000000004824f2 in fe_op_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730) at ../../../servers/slapd/bind.c:383 #17 0x00000000004822ea in do_bind (op=0x7f2c201039a0, rs=0x7f2c2a9aa730) at ../../../servers/slapd/bind.c:206 #18 0x0000000000466847 in connection_operation (ctx=<optimized out>, ctx@entry=0x7f2c2a9aa9b8, arg_v=arg_v@entry=0x7f2c201039a0) at ../../../servers/slapd/connection.c:1113 #19 0x0000000000465ec1 in connection_read_thread (ctx=<optimized out>, argv=0x11) at ../../../servers/slapd/connection.c:1265 #20 0x00007f2c72d5ea22 in ldap_int_thread_pool_wrapper (xpool=<optimized out>) at ../../../libraries/libldap/tpool.c:1053 #21 0x00007f2c70f5b1cf in start_thread () from /lib64/libpthread.so.0 #22 0x00007f2c70bc6e73 in clone () from /lib64/libc.so.6 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9997] New: Potential memory leak in servers/slapd/syncrepl.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9997 Issue ID: 9997 Summary: Potential memory leak in servers/slapd/syncrepl.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in syncrepl.c line 605.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9990] New: Part of the ITS#8698 fix breaks exop overlays that set a callback
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9990 Issue ID: 9990 Summary: Part of the ITS#8698 fix breaks exop overlays that set a callback Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: subbarao(a)computer.org Target Milestone: --- We have a password exop overlay that sets up a callback, which has stopped working when upgrading to 2.5.13. and I tracked it down to a change to servers/slapd/passwd.c implemented as part of the fix for ITS#8698: https://git.openldap.org/openldap/openldap/-/merge_requests/304/diffs?commi… It appears that the intent of this change was to loop through the o_callback list and only remove the cb callback created in this section of the code. But that isn't necessary because the cb callback never gets added to the original list. With this change, line 295 clobbers the original o_callback list which never gets restored -- that's why our exop overlay stopped working. Fortunately, the fix is very simple -- just revert this part of the change. The original code already saved/restored the o_callback list properly. When I reverted this part of the change, our exop overlay resumed working, and the rest of the ITS#8698 functionality (messages from the pwdCheckModule module being returned to the user) also worked as expected. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 10035] New: TLSv1.3 cipher suites can be set incorrectly
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10035 Issue ID: 10035 Summary: TLSv1.3 cipher suites can be set incorrectly Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ipuleston(a)sonicwall.com Target Milestone: --- I noticed that, on the client side, when I use LDAP_OPT_X_TLS_CIPHER_SUITE to set an OpenSSL cipher-suites list that contains a TLSv1.3 cipher suite, that may or may not get set correctly, depending on where it is located in the list. The following is what I am seeing with TLS versions 1.2 and 1.3 enabled: If I set this cipher-suites list: "3DES:TLS_AES_128_GCM_SHA256:!eNULL" Then WireShark shows shows it offering these ciphers in the TLS Client Hello, which is correct (the single given TLSv1.3 suite, plus 6 using 3-DES): Cipher Suites (7 suites) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) However, if I set this cipher-suites list: "!eNULL:3DES:TLS_AES_128_GCM_SHA256" Then it now incorrectly offers two additional TLSv1.3 suites: Cipher Suites (9 suites) Cipher Suite: TLS_AES_256_GCM_SHA384 (0x1302) Cipher Suite: TLS_CHACHA20_POLY1305_SHA256 (0x1303) Cipher Suite: TLS_AES_128_GCM_SHA256 (0x1301) Cipher Suite: TLS_ECDHE_ECDSA_WITH_3DES_EDE_CBC_SHA (0xc008) Cipher Suite: TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA (0xc012) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Cipher Suite: TLS_EMPTY_RENEGOTIATION_INFO_SCSV (0x00ff) Those first three are all of the TLSv3 ciphers supported by OpenSSL in this system. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10003] New: Potential Use After Free in libraries/libldap/open.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10003 Issue ID: 10003 Summary: Potential Use After Free in libraries/libldap/open.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential Use After Free in open.c line 590. Doc says "Once it(ldap_unbind) is called, the connection to the LDAP server is closed, and the ld structure is invalid." in https://www.openldap.org/software/man.cgi?query=ldap_unbind_ext&apropos=0&s… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9998] New: Potential memory leak in tests/progs/slapd-mtread.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9998 Issue ID: 9998 Summary: Potential memory leak in tests/progs/slapd-mtread.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in slapd-mtread.c line 520.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10048] New: adding a regex entry for overlay variant crashes slapd
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10048 Issue ID: 10048 Summary: adding a regex entry for overlay variant crashes slapd Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- I'm using symas-packages 2.6.4 on a Debian 11 system. Two providers with multi provider replication. I try to add different entries wit overlay "variant" first without regex. Here my ldif for the configuration: ----------- dn: cn=module{0},cn=config changetype: modify add: olcModuleLoad olcModuleLoad: variant.la ----------- ----------- dn: olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantConfig olcVariantPassReplication: TRUE dn: name=global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantVariant olcVariantEntry: dc=example,dc=net dn: olcVariantVariantAttribute=postaladdress,name={0}global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttribute olcVariantVariantAttribute: postaladdress olcVariantAlternativeAttribute: postaladdress olcVariantAlternativeEntry: ou=firma,dc=example,dc=net dn: name=company-phone,name={0}global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttribute olcVariantVariantAttribute: telephonenumber olcVariantAlternativeAttribute: mobile olcVariantAlternativeEntry: cn=verw-al,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net ----------- That works as expected. Then I wrote a ldif-file for variant WITH regex: ----------- dn: name=verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantRegex olcVariantEntryRegex: cn=.+,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net dn: olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config objectClass: olcVariantAttributePattern olcVariantVariantAttribute: telephoneNumber olcVariantAlternativeAttribute: telephoneNumber olcVariantAlternativeEntryPattern: ou=Verwaltung,ou=firma,dc=example,dc=net ----------- When I try to add the ldif with ldapadd slapd crashes with the following messages in the log: --------------- May 06 08:16:28 provider02 slapd[8018]: conn=1001 fd=20 ACCEPT from PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi) May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND dn="" method=163 May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL bind_ssf=0 ssf=71 May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 RESULT tag=97 err=0 qtime=0.000009 etime=0.000146 text= May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=1 ADD dn="name=verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config" May 06 08:16:28 provider02 slapd[8018]: slap_get_csn: conn=1001 op=1 generated new csn=20230506081628.055320Z#000000#001#000000 manage=1 May 06 08:16:28 provider02 slapd[8018]: slap_queue_csn: queueing 0x7f7c64012890 20230506081628.055320Z#000000#001#000000 May 06 08:16:28 provider02 slapd[8018]: olcVariantEntryRegex: value #0: <olcVariantEntryRegex> handler exited with 19! May 06 08:16:28 provider02 systemd[1]: symas-openldap-server.service: Main process exited, code=killed, status=11/SEGV May 06 08:16:28 provider02 systemd[1]: symas-openldap-server.service: Failed with result 'signal'. --------------- Even if olcVariantEntryRegex is wrong (what I don't know up to now) slapd should not crash. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10015] New: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES KEEPALIVE_INTERVAL parser does random memory write
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10015 Issue ID: 10015 Summary: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES KEEPALIVE_INTERVAL parser does random memory write Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: sean(a)teletech.com.au Target Milestone: --- In openldap/libraries/libldap/init.c: [master branch] The Config File integers KEEPALIVE_IDLE KEEPALIVE_PROBES KEEPALIVE_INTERVAL Should be struct ol_attribute.type ATTR_OPT_INT rather than ATTR_INT. ATTR_INT interprets struct ol_attribute.offset as a pointer to integer. ATTR_OPT_INT interprets struct ol_attribute.offset as an option number to be passed to ldap_set_option() -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10016] New: syncprov may abandon a psearch improperly
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10016 Issue ID: 10016 Summary: syncprov may abandon a psearch improperly Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When processing an Abandon, it may remove the detached search op from the connection while the qtask is actively sending search responses on the connection. If the Abandon is due to an Unbind or connection loss, the connection structure may get reused by a new conn while the qtask is still running. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9953] New: Push replication issue for the pwdHistory attribute
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9953 Issue ID: 9953 Summary: Push replication issue for the pwdHistory attribute Product: OpenLDAP Version: 2.4.57 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dh(a)dotlan.net Target Milestone: --- Hello, I'm using a master ldap instance with a push replication instance to external slaves using the ldap backend on Debian 11 (2.4.57) and I came across some replication issues that forces me to drop the slave dbs and do a manually fullsync everything this error occurs. The problem =========== I know that replication and maintaining a password policy is a complicated task, especially since the ppolicy overlay must be loaded and active in every instance (master, push instance, slave). This problem leads to interesting challanges. First, I encountered a problem where pwdChangedTime would be duplicate because the ppolicy overlay of the push instance and the back_ldap/slave instance would like to set it (which leads to a duplicate attribute error). To fix problem I backported the patch [1] to my local version of the slapd packages. After this problem was fixed, I've encountered the next problematic attribute: "pwdHistory". I've play around with some syncrepl settings, but in the end, it seems to be a similar issue. It looks likes the pwdHistory attribute is not yet present on the slave and both instances (push and slave) try to add the pwdHistory Attributes which leads to a problem where both entries collied (pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't show up as modified field on the slave in the MOD request. But anyways. Something seems to be wrong, and it could a similar replication issue compared with pwdChangedTime I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6 branch but couldn't find a newer commit that would address this issue. Does anyone has encountered a similar issue? I've not played around with the 2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the problem might still exist, hopefully I am wrong. Any suggestions? -- best regards Daniel Hoffend [1] https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b62152… Setup ===== Host Master - Debian 11 slapd 2.4.57+dfsg-3 - slapd master instance with cn=config - push replikation instance with simple config (syncrepl from localhost, write to backend ldap) Host Slave - Debian 11 slapd 2.4.57+dfsg-3 - Readonly slave On all 3 instances ppolicy is enabled otherwise the operational attributes would be not known/available and sync of locked accounts or per account selected password policy assignment wouldn't work. PUSH Replication Instance ========================= database ldap [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org" syncrepl rid=__RID__ provider=ldap://localhost:389/ binddn="cn=replication,ou=system,dc=example,dc=org" bindmethod=simple credentials="secret" searchbase="dc=example,dc=org" type=refreshAndPersist schemachecking=off retry="5 12 60 +" attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp" --- Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016 DN: uid=user1,ou=accounts,dc=example,dc=org, UUID: db720f56-df0d-103c-8635-9543ccd6e97d Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search (0) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 uid=user1,ou=accounts,dc=example,dc=org Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code 0x14 Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify uid=user1,ou=accounts,dc=example,dc=org (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify failed (20) Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying SLAVE LDAP Server ================= database mdb [...] overlay ppolicy ppolicy_default "cn=default,ou=policies,dc=example,dc=org" --- Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0 filter="(objectClass=*)" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT tag=101 err=0 nentries=1 text= Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD dn="uid=user1,ou=accounts,dc=example,dc=org" Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD attr=structuralObjectClass creatorsName createTimestamp userPassword pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103 err=20 text=modify/add: pwdHistory: value #0 already exists -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10004] New: Potential memory leak in libraries/librewrite/ldapmap.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10004 Issue ID: 10004 Summary: Potential memory leak in libraries/librewrite/ldapmap.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in ldapmap.c line 310, 321.Calling ldap_initialize() without calling ldap_unbind_ext() to free the memory will cause a memory leak. There is no ldap_unbind_ext before calling ldap_initialize in line 376, and the ld will be allocated again. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10037] New: Instructions for building argon2.so are inaccurate
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10037 Issue ID: 10037 Summary: Instructions for building argon2.so are inaccurate Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: sclassen(a)lbl.gov Target Milestone: --- The instructions for building the argon2.so shared library are inaccurate. According to: servers/slapd/pwmods/README.argon2 Building -------- 1) Customize the OPENLDAP variable in Makefile to point to the OpenLDAP source root. For initial testing you might also want to edit DEFS to define SLAPD_ARGON2_DEBUG, which enables logging to stderr (don't leave this on in production, as it prints passwords in cleartext). 2) Run 'make' to produce argon2.so 3) Copy argon2.so somewhere permanent. 4) Edit your slapd.conf (eg. /etc/ldap/slapd.conf), and add: moduleload ...path/to/argon2.so 5) Restart slapd. When I run make from within servers/slapd/pwmods/ I get the following error: [user@machine openldap-2.6.4]# cd servers/slapd/pwmods/ [user@machine pwmods]# make make: *** No rule to make target 'dummyvalue', needed by 'all-common'. Stop. I’m not sure what “dummyvalue” is supposed to be so I commented out line 288 in servers/slapd/pwmods/Makefile # LIBRARY = dummyvalue And get this error: [user@ machine pwmods]# make /bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c libtool: compile: cc -g -O2 -I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c version.c -fPIC -DPIC -o .libs/version.o version.c:1:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘:’ token usage: mkversion [-c] [-s] [-p package] [-v version] application ^ make: *** [Makefile:310: version.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10033] New: olcDbCacheSize in mdb configuration example
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10033 Issue ID: 10033 Summary: olcDbCacheSize in mdb configuration example Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- on Page: https://openldap.org/doc/admin26/overlays.html#The%20Proxy%20Cache%20Engine There is an example for pcache-db configuration for a mdb-database: ----------- dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config objectClass: olcMdbConfig objectClass: olcPcacheDatabase olcDatabase: {0}mdb olcDbDirectory: ./testrun/db.2.a olcDbCacheSize: 20 olcDbIndex: objectClass eq olcDbIndex: cn,sn,uid,mail pres,eq,sub ----------- But olcDbCacheSize is an bdb/hdb attribute. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9999] New: Potential memory leak in tests/progs/slapd-search.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9999 Issue ID: 9999 Summary: Potential memory leak in tests/progs/slapd-search.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in slapd-search.c line 207.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10046] New: Wrong ObjectClass Name in example in manpage slapo-variant
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10046 Issue ID: 10046 Summary: Wrong ObjectClass Name in example in manpage slapo-variant Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: stefan(a)kania-online.de Target Milestone: --- Manpage is telling: ---------- # share the Headquarters' address as the company address dn: olcVariantVariantAttribute=postaladdress,name={0}example,olcOverlay={x}variant,$DATABASE objectClass: olcVariantVariantAttribute olcVariantVariantAttribute: postaladdress olcVariantAlternativeAttribute: postaladdress olcVariantAlternativeEntry: ou=Headquarters,dc=example,dc=com ---------- But the name of the ObjectClass is objectClass=olcVariantAttribute -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9996] New: Potential memory leak in libraries/librewrite/ldapmap.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9996 Issue ID: 9996 Summary: Potential memory leak in libraries/librewrite/ldapmap.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in ldapmap.c line 359.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10030] New: Add support for OpenSSL 3.0 to 2.5 stable release
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10030 Issue ID: 10030 Summary: Add support for OpenSSL 3.0 to 2.5 stable release Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- As OpenSSL 1.1.1 is being sunset September 2023 we will need to add OpenSSL 3.0 support to the 2.5 series. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10041] New: unnecessary dynlist evaluation
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10041 Issue ID: 10041 Summary: unnecessary dynlist evaluation Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Created attachment 963 --> https://bugs.openldap.org/attachment.cgi?id=963&action=edit openldap config + data for showing the dynlist usecase Evaluation of member of dynamic groups by dynlist can be slow. However, in some context, the evaluation is not necessary, especially when searching object that are not dynamic groups. You can find attached a configuration and data file showing the use case: - 10000 users - 100 static groups - 5000 dynamic groups, with a filter (&(uid=user*)(objectClass=person), grabbing all users Example of "normal" slow search ~ 115s: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(member=uid=user1,ou=people,dc=my-organization,dc=com)' Example of abnormal slow search ~ 115s: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))' Here, the filter about the objectClass could be evaluated first to avoid unnecessary search in dynamic groups. Example of rapid search with DSA IT ~ 1ms: ldapsearch -x -H 'ldap://localhost:389/' -D 'uid=admin,ou=people,dc=my-organization,dc=com' -w 'secret' -b 'ou=groups,dc=my-organization,dc=com' '(&(objectClass=groupOfNames)(member=uid=user1,ou=people,dc=my-organization,dc=com))' -M -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10000] New: Potential memory leak in tests/progs/slapd-watcher.c
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10000 Issue ID: 10000 Summary: Potential memory leak in tests/progs/slapd-watcher.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1061499390(a)qq.com Target Milestone: --- Version: Github:master Potential memory leak in slapd-watcher.c line 517.Calling ldap_search_ext_s() without calling ldap_msgfree() to free the memory will cause a memory leak. Doc says "Note that res parameter of ldap_search_ext_s() and ldap_search_s() should be freed with ldap_msgfree() regardless of return value of these functions." in https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0… -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10023] New: Asynchronous connects are broken
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10023 Issue ID: 10023 Summary: Asynchronous connects are broken Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ipuleston(a)sonicwall.com Target Milestone: --- We have a port of OpenLDAP client running in an embedded system, which is using asynchronous connects to the LDAP server. We have been using OpenLDAP 2.4.40 for a long time, and I just upgraded it to use 2.5.14 (as the current LTS release). After doing this, async connects to the LDAP server no longer work. You can see this in the following debug output: A successful async connect with 2.4.40: ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP Ian-DC1.sd80.com:389 ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0 ldap_new_socket: 251 ldap_prepare_socket: 251 ldap_connect_to_host: Trying 192.168.168.3:389 ldap_pvt_connect: fd: 251 tm: 10 async: -1 ldap_ndelay_on: 251 attempting to connect: connect errno: 115 ldap_int_poll: fd: -1 tm: 0 A failed async connect with 2.5.14: ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP Ian-DC1.sd80.com:389 ldap_pvt_gethostbyname_a: host=Ian-DC1.sd80.com, r=0 ldap_new_socket: 247 ldap_prepare_socket: 247 ldap_connect_to_host: Trying 10.21.61.3:389 ldap_pvt_connect: fd: 247 tm: 10 async: -1 ldap_ndelay_on: 247 attempting to connect: connect errno: 115 ldap_open_defconn: successful ldap_send_server_request Sending Bind Request, len=0x6ca10c1f ldap_write: want=63 error=Resource temporarily unavailable Note that in both cases the connect attempt returns errno 115, EINPROGRESS, meaning that it has not completed. But after that: ● 2.4.40 calls ldap_int_poll (via ldap_send_initial_request -> ldap_int_check_async_open) to begin the wait for async completion. ● 2.5.14 instead reports a successful connect, and tries to send the bind which fails since thre socket is not yet connected. I tracked the problem down to a change made for ITS #8022 "an async connect may still succeed immediately" in this commit: https://git.openldap.org/openldap/openldap/-/commit/ae6347bac12bbf843678a83… That change in ldap_new_connection makes it set lconn_status for an async connect to LDAP_CONNST_CONNECTED rather than LDAP_CONNST_CONNECTING if ldap_int_open_connection returns 0. The problem is that ldap_int_open_connection returns 0 after getting the EINPROGRESS. ldap_connect_to_host returns -2 for the latter, but ldap_int_open_connection doesn't check for that, returning 0 for any return code other than -1. I think that the bug is actually in ldap_int_open_connection rather than in the above commit. It should probably return -2 when ldap_connect_to_host returns that. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10011] New: Incompatibilities with stricter C99 compilers
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10011 Issue ID: 10011 Summary: Incompatibilities with stricter C99 compilers Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: sam(a)gentoo.org Target Milestone: --- Newer C compilers (>= Clang 16 and likely >= GCC 14) reject some constructs removed in C99 like implicit function declarations and implicit ints. Some compilers are also starting to reject obsolete K&R prototypes which were removed in C23. I've filed an MR at https://git.openldap.org/openldap/openldap/-/merge_requests/605 to address the issues in configure as well as a small number of issues in the codebase itself. For more information, see LWN.net [0] or LLVM's Discourse [1], the Gentoo wiki [2], or the (new) c-std-porting mailing list [3]. [0] https://lwn.net/Articles/913505/ [1] https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-… [2] https://wiki.gentoo.org/wiki/Modern_C_porting [3] hosted at lists.linux.dev. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10079] New: Facing syncrepl issue after selecting filter and attrs
by openldap-its＠openldap.org 06 Jul '23

06 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10079 Issue ID: 10079 Summary: Facing syncrepl issue after selecting filter and attrs Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ramprasad.sharma(a)orange.com Target Milestone: --- I'm facing an issue, when I'm using replication without filter and attrs, it works fine but when I try it with filter and attrs , I get nentries=0 and replication dont happen.. what could be the possible issue, I tried many thing.. syncrepl rid=<%= @%> provider=ldaps://master.<%= @%>h:636/ bindmethod=simple binddn="cn=replication,dc=di-diod,dc=tech" credentials=<%= @%> searchbase="ou=people,dc=di-diod,dc=tech" filter="(objectClass=posixAccount)" attrs="cn,uid,x1sshPubKey,x2sshPubKey,uidNumber,gidNumber,homeDirectory,gecos,loginShell,description,sshPublicKey" scope=sub schemachecking=on type=refreshOnly interval=00:00:00:01 retry="30 5 300 3" I can use any help on call also.. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs