- openldap-bugs - openldap.org

[Issue 10093] New: Unclear licenses in certain places
by openldap-its＠openldap.org 14 Sep '23

14 Sep '23

https://bugs.openldap.org/show_bug.cgi?id=10093 Issue ID: 10093 Summary: Unclear licenses in certain places Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: thegeorg(a)yandex-team.com Target Milestone: --- We use scancode-toolkit in order to perform automatic license analysis. At the time, this toolkit reports certain places with unclear license status. In particular, libraries/libldap/modrdn.c (lines 19 to 24) bear the following notice: ``` /* Copyright 1999, Juan C. Gomez, All rights reserved. * This software is not subject to any license of Silicon Graphics * Inc. or Purdue University. * * Redistribution and use in source and binary forms are permitted * without restriction or fee of any kind as long as this notice * is preserved. */ ``` While copyright notice is completely fine, the second part can not be recognised as any SPDX acknowledged license. Is it possible to unify the text across other parts of OpenLDAP? -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10058] New: destroying robust mutexes leads to use of an uninitialized mutex
by openldap-its＠openldap.org 27 Aug '23

27 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10058 Issue ID: 10058 Summary: destroying robust mutexes leads to use of an uninitialized mutex Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: jiri.novosad(a)gmail.com Target Milestone: --- Created attachment 966 --> https://bugs.openldap.org/attachment.cgi?id=966&action=edit an example program to reproduce the bug This is a regression introduced in https://bugs.openldap.org/show_bug.cgi?id=9278 . The issue is that mdb_env_setup_locks initializes the mutex only when it gets an exclusive fcntl file lock. But there is this possible order of operations: 1. Process A opens the DB, gets an exclusive file lock, initializes the mutex, downgrades the file lock to shared and does its thing 2. Process A closes the env: it gets an exclusive lock and destroys the mutex 3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the shared lock 4. Process A finishes closing the env, closes the file descriptor and loses the file lock 5. Process B gets the shared lock, does not initialize the mutex in mdb_env_setup_locks (because it does not have the exclusive lock) 6. Process B tries to lock the mutex, but it is not initialized, pthread_mutex_lock returns EINVAL -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 6166] Overlay/backend restructuring
by openldap-its＠openldap.org 24 Aug '23

24 Aug '23

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

1 0

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 21 Aug '23

21 Aug '23

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

1 0

[Issue 7226] olcAuditlogFile should be single valued, but accepts multiple values (additional values ignored)
by openldap-its＠openldap.org 18 Aug '23

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|olcAuditlogFile At dos not |olcAuditlogFile should be |accept multiple values |single valued, but accepts | |multiple values (additional | |values ignored) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7226] olcAuditlogFile At dos not accept multiple values
by openldap-its＠openldap.org 18 Aug '23

18 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=7226 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Resolution|FEEDBACK |--- --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Root problem of this being treated as single value, but accepting multiple values (additional values are ignored) has never been addressed, which was the original bug report here. The matching rule issue was already fixed. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10086] New: test059 does not set up valid cn=config replication
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10086 Issue ID: 10086 Summary: test059 does not set up valid cn=config replication Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For cn=config replication to be valid, the entryUUIDs must match throughout the config database. However, this is not the case when test059 executes. The entryUUID for 'dn: cn=config' differs between the two. Example: quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: cfcon.d/cn\=config.ldif entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372 quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID: db.1.a/cn\=config\,cn\=consumer.ldif entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22 -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10090] New: regex that contains a quoted literal space or escaped space results in a parse error
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10090 Issue ID: 10090 Summary: regex that contains a quoted literal space or escaped space results in a parse error Product: OpenLDAP Version: 2.6.6 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gburd(a)symas.com Target Milestone: --- Searching ACLs using regex expressions should allow for white space. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before\ After,o=example[.]com,c=US$" read by * break or olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[ ]After,o=example[.]com,c=US$" read by * break or any regex that contains a literal space results in a parse error. It seems like the string is broken on literal spaces irrespective of quoting. Debug output from slapd: 64cd845c.253aa590 0x7fe6f4fc9640 slapd: line 0: regular expression "ou=Before\" bad because of Trailing backslash This should also include other methods for expressing white space such as `:space:` or `\w` pattern matches. olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[[:space:]]After,o=example[.]com,c=US$" read by * break -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10073] New: database monitor | slapd fails to start when "database ldap" without suffix exists
by openldap-its＠openldap.org 14 Aug '23

14 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10073 Issue ID: 10073 Summary: database monitor | slapd fails to start when "database ldap" without suffix exists Product: OpenLDAP Version: 2.5.14 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: cyusedfzfb(a)gmail.com Target Milestone: --- As requested on the mailinglist, I am filing an issue for this behaviour: Today setup the cn=Monitor backend, and after doing so, openldap failed to start with: backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed! (-1) The reason turned out to be: we had configured one of our databases ("database ldap") without a suffix. After I added a suffix, openldap started, and cn=Monitor worked as expected. It would be nice if this error message could become a little bit more specific. :-) Also: we've had the "database ldap" without a suffix in production working for many years. Perhaps cn=Monitor should be able to deal with that config as well..? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10088] New: "DN index add failed" when renaming an entry
by openldap-its＠openldap.org 08 Aug '23

08 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=10088 Issue ID: 10088 Summary: "DN index add failed" when renaming an entry Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: git(a)zifbang.com Target Milestone: --- I recently updated a Docker image to the latest Debian release, which means I got a new OpenLDAP version: 2.5.13 (not sure what it was before, but definitely <=2.4.x). The old image's backend was HDB. That disappeared, so I made changes(1) to use the default MDB store. Today I found out that one of my tests is failing against this new image with a "DN index add failed" message. I traced the message down to (2), but I don't understand what is causing the message to be generated and cannot find any documentation on the function that returned the error. Basically, the test is renaming an entry to a very long name. This script shows the error: ```sh #!/usr/bin/env bash set -e function cleanup() { echo "Stopping server..." docker stop ldap-test 2>&1 1>/dev/null } trap cleanup EXIT echo "Starting server..." docker run --rm -d \ -p 1389:389 -p 1636:636 \ --name ldap-test \ ghcr.io/ldapjs/docker-test-openldap/openldap:2023-07-25 2>&1 1>/dev/null echo "Waiting for server to start..." sleep 3 echo "Renaming entry..." docker exec ldap-test \ ldapmodrdn -x -H ldapi:/// \ -D 'cn=admin,dc=planetexpress,dc=com' \ -w 'GoodNewsEveryone' \ -v -d 2 \ 'cn=Turanga Leela,ou=people,dc=planetexpress,dc=com' \ 'cn=a292979f2c86d513d48bbb9786b564b3c5228146e5ba46f404724e322544a7304a2b1049168803a5485e2d57a544c6a0d860af91330acb77e5907a9e601ad1227e80e0dc50abe963b47a004f2c90f570450d0e920d15436fdc771e3bdac0487a9735473ed3a79361d1778d7e53a7fb0e5f01f97a75ef05837d1d5496fc86968ff47fcb64' ``` What changes do I need to make in order to solve this error? I have tried applying the following ldif to my image creation, but it does not solve the problem: ```ldif dn: cn=config changetype: modify replace: oldIndexHash64 olcIndexHash64: TRUE ``` 1: https://github.com/ldapjs/docker-test-openldap/pull/3/files 2: https://git.openldap.org/openldap/openldap/-/blob/2738a32de3a324fc56effd44c… -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 08 Aug '23

08 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=8461 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 10088 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8461] Unable to import LDIF from back-hdb DB to back-mdb db
by openldap-its＠openldap.org 02 Aug '23

02 Aug '23

https://bugs.openldap.org/show_bug.cgi?id=8461 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |git(a)zifbang.com --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 10088 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10067] New: back-meta doesn't like an empty modify
by openldap-its＠openldap.org 31 Jul '23

31 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10067 Issue ID: 10067 Summary: back-meta doesn't like an empty modify Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A modify like: dn: <dn> changetype: modify sent to a back-meta DB will trigger an assert on ch_malloc(0). The code also kind of takes liberty at equating free and ch_free, which could backfire under some (extremely rare) circumstances. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10081] New: slapacl lists wrong permissions when peername.ip is used in ACL
by openldap-its＠openldap.org 31 Jul '23

31 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10081 Issue ID: 10081 Summary: slapacl lists wrong permissions when peername.ip is used in ACL Product: OpenLDAP Version: 2.5.14 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: carsten.jaeckel(a)tu-dortmund.de Target Milestone: --- in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following ACLs in olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything works as expected. LDAP-Log: 2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from IP=10.10.10.10:53558 (IP=0.0.0.0:636) 2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS established tls_ssf=128 ssf=128 tls_proto=TLSv1.3 tls_cipher=TLS_AES_128_GCM_SHA256 2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" method=128 2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128 2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97 err=0 qtime=0.000014 etime=0.002242 text= 2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD dn="cn=test,ou=users,dc=foo,dc=bar" 2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD attr=description 2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT tag=103 err=0 qtime=0.000022 etime=0.069664 text= 2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed (connection lost) Running the above command from another machine results in a Insufficient access (50) error as also expected. So I assume the ACLs to be working correctly. If I run slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 I get the following output: PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: none(=0) children: none(=0) description=test: none(=0) cn=test: none(=0) sn=test: none(=0) objectClass=person: none(=0) objectClass=top: none(=0) structuralObjectClass=person: none(=0) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0) creatorsName=cn=manager,dc=foo,dc=bar: none(=0) createTimestamp=20230227131940Z: none(=0) userPassword=****: none(=0) pwdChangedTime=20230227131959Z: none(=0) authTimestamp=20230616065542Z: none(=0) pwdLastSuccess=20230616103806Z: none(=0) entryCSN=20230616103806.257186Z#000000#000#000000: none(=0) modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0) modifyTimestamp=20230616103806Z: none(=0) I expected to see write access in slapacl's output. If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by * none the above slapacl command outputs write access correctly no matter if the parameter '-o peername=10.10.10.10' is set or not. olcAccess: {0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to * by self read by anonymous auth by * none break slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar PROXIED attributeDescription "OU" inserted. PROXIED attributeDescription "DC" inserted. authcDN: "cn=test,ou=users,dc=foo,dc=bar" entry: write(=wrscxd) children: write(=wrscxd) description=first test cn=test: write(=wrscxd) sn=test: write(=wrscxd) objectClass=person: write(=wrscxd) objectClass=top: write(=wrscxd) structuralObjectClass=person: write(=wrscxd) entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd) creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd) createTimestamp=20230227131940Z: write(=wrscxd) userPassword=****: write(=wrscxd) pwdChangedTime=20230227131959Z: write(=wrscxd) authTimestamp=20230616065542Z: write(=wrscxd) pwdLastSuccess=20230616105312Z: write(=wrscxd) entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd) modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd) modifyTimestamp=20230616105330Z: write(=wrscxd) -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10047] New: slapd SEGV after slapindex -q
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10047 Issue ID: 10047 Summary: slapd SEGV after slapindex -q Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In an environment where cn=config is replicated: a) Added an equality index for an existing attribute b) Stopped slapd after the change to the configuration had been replicated to the server. The indexing process that was automatically kicked off by this had been running for ~30 minutes before I stopped slapd c) ran: slapindex -q -F /path/to/config -b <base> <attr> d) started slapd e) segfault To verify it wasn't an overall data issue, I then: a) slapcat the database b) moved the problem database files aside for debugging c) reloaded the database with slapadd -q d) everything works fine I will attach the gdb output to this ticket momentarily -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 10042] New: Crash when back-monitor search fails/is abandoned
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10042 Issue ID: 10042 Summary: Crash when back-monitor search fails/is abandoned 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: --- The fix in ITS#9832 was incomplete, some paths leading to "freeout:" can have passed through monitor_cache_release already. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9993] New: Potential race condition in back-mdb online indexer
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=9993 Issue ID: 9993 Summary: Potential race condition in back-mdb online indexer Product: OpenLDAP Version: 2.5.13 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When the online indexer completes, it should mutex-protect its resetting of the indexing flags. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 10031] New: Conversion of slapd.conf fails using pcache
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10031 Issue ID: 10031 Summary: Conversion of slapd.conf fails using pcache Product: OpenLDAP Version: 2.6.0 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've got the following working slapd.conf: -------------------- include /opt/symas/etc/openldap/schema/core.schema include /opt/symas/etc/openldap/schema/cosine.schema include /opt/symas/etc/openldap/schema/inetorgperson.schema include /opt/symas/etc/openldap/schema/misc.schema include /opt/symas/etc/openldap/schema/nis.schema include /opt/symas/etc/openldap/schema/msuser.schema modulepath /opt/symas/lib/openldap moduleload back_ldap moduleload back_mdb moduleload rwm.la moduleload memberof.la moduleload pcache.la loglevel any pidfile /var/symas/run/slapd.pid argsfile /var/symas/run/slapd.args database ldap readonly yes protocol-version 3 rebind-as-user yes uri "ldap://192.168.56.201:389" suffix "dc=example1,dc=net" rootdn "cn=admin,dc=example1,dc=net" idassert-bind bindmethod=simple mode=none binddn="CN=Administrator,cn=users,dc=example1,dc=net" credentials=Passw0rd tls_cacertdir=/opt/symas/etc/openldap tls_reqcert=never idassert-authzFrom "*" overlay rwm rwm-map attribute uid sAMAccountName rwm-map objectClass posixAccount person overlay memberof memberof-group-oc groupOfuniqueNames memberof-member-ad uniquemember memberof-dangling error overlay pcache pcache mdb 100000 6 1000 100 pcachePersist TRUE directory "/var/symas/pcache" pcacheAttrset 0 1.1 pcacheTemplate (uid=) 0 3600 pcacheTemplate (&(|(objectClass=))) 0 3600 pcacheAttrset 1 employeetype givenName cn sn uid mail pcacheTemplate (uid=) 1 3600 pcacheBind (uid=) 1 3600 sub dc=de pcacheAttrset 2 givenName cn sn uid mail uidNumber pcacheTemplate (objectClass=) 2 3600 pcacheAttrset 3 userPassword pcacheTemplate (uid=) 3 3600 pcacheTemplate (objectClass=) 2 3600 pcacheAttrset 4 employeetype givenName cn sn uid mail pcacheTemplate (uid=) 1 3600 pcacheAttrset 5 memberOf pcacheTemplate (objectClass=*) 2 3600 -------------------- Search for an entry in AD is working: ---------------------- root@ldap-proxy01:~/server-setup/proxy# ldapsearch -x -b dc=example1,dc=net cn=administrator -LLL dn dn: cn=Administrator,cn=Users,dc=example1,dc=net ---------------------- Now I want convert it to cn=config but I'm getting the following error: -------------------- root@ldap-proxy01:/opt/symas/etc/openldap# slaptest -F ./my-slapd.d/ -f slapd.conf Entry (olcDatabase={0}mdb,olcOverlay={2}pcache,olcDatabase={1}ldap,cn=config): object class 'olcMdbBkConfig' requires attribute 'olcBackend' config_build_entry: build "olcDatabase={0}mdb" failed: "(null)" config file testing succeeded mdb_opinfo_get: err Permission denied(13) -------------------- When I comment out all the settings for the overlay pcache, converting slapd.conf is working, but starting slapd gives me the following error: -------------- Mär 27 20:02:03 ldap-proxy01 slapd[2042]: olcAttributeTypes: value #741 olcAttributeTypes: Duplicate attributeType: "" Mär 27 20:02:03 ldap-proxy01 slapd[2042]: config error processing cn={5}msuser,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "" Mär 27 20:02:03 ldap-proxy01 slapd[2042]: send_ldap_result: conn=-1 op=0 p=0 Mär 27 20:02:03 ldap-proxy01 slapd[2042]: send_ldap_result: err=80 matched="" text="" -------------- slapcat -n0 tells me: -------------- root@ldap-proxy01:/opt/symas/etc/openldap# slapcat -n0 olcAttributeTypes: value #741 olcAttributeTypes: Duplicate attributeType: "�p�:V" config error processing cn={5}msuser,cn=schema,cn=config: olcAttributeTypes: Duplicate attributeType: "�p�:V" slapcat: bad configuration file! -------------- But switching back to slapd.conf the msuser.schema makes no problems. Creating my own LDIF (without converting): -------------------------- dn: cn=config objectClass: olcGlobal cn: config olcLogLevel: any olcPidFile: /var/symas/run/slapd.pid olcArgsFile: /var/symas/run/slapd.args olcToolThreads: 1 dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /opt/symas/lib/openldap olcModuleLoad: back_mdb olcModuleLoad: back_ldap olcModuleLoad: back_monitor olcModuleLoad: argon2 include: file:///opt/symas/etc/openldap/schema/core.ldif include: file:///opt/symas/etc/openldap/schema/cosine.ldif include: file:///opt/symas/etc/openldap/schema/nis.ldif include: file:///opt/symas/etc/openldap/schema/inetorgperson.ldif include: file:///opt/symas/etc/openldap/schema/msuser.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcSizeLimit: 500 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {1}to dn="" by * read olcAccess: {2}to dn.base="cn=subschema" by * read passwordHash: {ARGON2} dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2i$v=19$m=4096,t=3,p=1$cXdlcnJ0enV6dWlvMTIz$G/l0lynf7ygdz0tG+E7S1fBibsFs/L80AUSisiGl/v4 olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage dn: olcDatabase={1}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {1}monitor olcAccess: {0}to dn.subtree="cn=monitor" by dn.exact=cn=admin,cn=config read by dn.exact=cn=admin,dc=example,dc=net read by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth read dn: olcDatabase={2}ldap,cn=config objectClass: olcDatabaseConfig objectClass: olcLDAPConfig olcDatabase: {2}ldap olcSuffix: dc=example1,dc=net olcAddContentAcl: FALSE olcLastMod: FALSE olcLastBind: FALSE olcLastBindPrecision: 0 olcMaxDerefDepth: 15 olcReadOnly: TRUE olcRootDN: cn=admin,dc=example1,dc=net olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcDbURI: "ldap://dc-net01.example.net:389" olcDbStartTLS: none starttls=no olcDbIDAssertBind: mode=none flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn="cn=administrator,cn=users,dc =example1,dc=net" credentials="Passw0rd" keepalive=0:0:0 tcp-user-timeout=0 t ls_cacertdir="/opt/symas/etc/openldap" tls_reqcert=never tls_reqsan=allow tls _crlcheck=none olcDbIDAssertAuthzFrom: * olcDbRebindAsUser: TRUE olcDbChaseReferrals: FALSE olcDbTFSupport: no olcDbProxyWhoAmI: FALSE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 -------------------------- msuser is working, no error about duplicate attributeType. System ist Debian 11 with symas-packages OpenLDAP 2.6 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 10063] New: Typo in configure.ac for SLAPD_DYNAMIC_PWMODS
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10063 Issue ID: 10063 Summary: Typo in configure.ac for SLAPD_DYNAMIC_PWMODS 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: quanah(a)openldap.org Target Milestone: --- As noted in -technical discussion: By the way, while looking at the code, I noticed a typo in configure.ac: > if test "$ol_enable_argon2" = "yes" ; then > SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la" > fi ^^ ^^^ It's referencing two different variables there, which is harmless today, but will be a build bug once multiple password modules become available. SLAPD_DYNAMIC_PWMODS is the correct one. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10039] New: configure fails to detect SSL_export_keying_material_early with LibreSSL
by openldap-its＠openldap.org 10 Jul '23

10 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10039 Issue ID: 10039 Summary: configure fails to detect SSL_export_keying_material_early with LibreSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orbea(a)riseup.net Target Milestone: --- Created attachment 957 --> https://bugs.openldap.org/attachment.cgi?id=957&action=edit config.log When configuring OpenLDAP using --with-tls=openssl with LibreSSL the configure will fail to detect SSL_export_keying_material_early since LibreSSL doesn't support this function yet. However OpenLDAP doesn't actually use this function so this can be easily solved by checking for SSL_library_init which is a more standard function which both OpenSSL and LibreSSL support which OpenLDAP actually uses in libraries/libldap/tls_o.c. checking openssl/ssl.h usability... yes checking openssl/ssl.h presence... yes checking for openssl/ssl.h... yes checking for SSL_export_keying_material_early in -lssl... no configure: error: Could not locate TLS/SSL package Other than this the build succeeds correctly with at least LibreSSL 3.7. -- You are receiving this mail because: You are on the CC list for the issue.

1 21

[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 05 Jul '23

05 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

[Issue 10078] New: segfault error 4 in in dynlist-2.5.so.0.1.8
by openldap-its＠openldap.org 05 Jul '23

05 Jul '23

https://bugs.openldap.org/show_bug.cgi?id=10078 Issue ID: 10078 Summary: segfault error 4 in in dynlist-2.5.so.0.1.8 Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: gustav(a)spllg.de Target Milestone: --- whenever i execute an ldapsearch, slapd crashes and i find the following lines in /var/log/syslog segfault at 0 ip 00007f876bece9c1 sp 00007f876a1fc0c0 error 4 in dynlist-2.5.so.0.1.8[7f876becb000+6000] likely on CPU 0 (core 0, socket 0) Code: 48 29 d0 48 89 d7 48 89 c1 31 c0 83 c1 6c c1 e9 03 f3 48 ab 48 8b 84 24 10 02 00 00 4c 89 ef c7 84 24 a0 00 00 00 03 00 00 00 <48> 8b 00 ff 50 78 44 39 73 64 74 09 45 84 e4 0f 85 22 03 00 00 48 Stopping OpenLDAP: slapd. slapd.service: Deactivated successfully. the database had been imported from ldap-2.4.57 where ldap runs fine. is there anything i can do to fix the problem? -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10075] New: back-sql regression between 2.4.40 and 2.4.44
by openldap-its＠openldap.org 28 Jun '23

28 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10075 Issue ID: 10075 Summary: back-sql regression between 2.4.40 and 2.4.44 Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: daniel.walker(a)ncas.ac.uk Target Milestone: --- I have just upgraded from CentOS6 to CentOS7 ( I know, not my pick :). On OpenLdap back-sql 2.4.40 on CentOS6, this seems to be honoured: "Multiple attributeType definitions are allowed for an entry; that is, multiple ldap_attr_mappings rows can refer to the same ldap_oc_mappings row with the same name; the resulting attribute values are honored for multivalued attributes in search filters, in search results, in compare AVAs. However, only rules according to the first instance of that attributeType are followed in add, modify and delete operations. This limitation, under certain circumstances, may be removed in the future." (from https://www.openldap.org/faq/data/cache/978.html ) I was using this feature to get memberAddress attributes from two separate tables in my SQL (internal people and external people) Upon upgrading to 2.4.44 on CentOS7, the second entry is no longer honoured. Relevant entries: MariaDB [ncas_database]> SELECT name,sel_expr,from_tbls,join_where,add_proc,delete_proc,param_order,expect_return,sel_expr_u FROM ldap_attr_mappings WHERE oc_map_id=4 AND name='memberAddress'; +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | name | sel_expr | from_tbls | join_where | add_proc | delete_proc | param_order | expect_return | sel_expr_u | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ | memberAddress | CONCAT(emails.address,"@domain.name") | groups,people_groups AS ps,people,emails | groups.id=ps.group_id AND ps.person_id=people.id AND people.id=emails.person_id AND emails.main=1 AND (people.contract_end > NOW() OR people.contract_end IS NULL) | NULL | NULL | 3 | 0 | NULL | | memberAddress | email | groups,external_members | groups.id=external_members.group_id | NULL | NULL | 3 | 0 | NULL | +---------------+--------------------------------------+------------------------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------+----------+-------------+-------------+---------------+------------+ 2 rows in set (0.000 sec) The second one is ignored; no requests to the external_members table show in the logs. Is this a known bug? I did look through the archives, but I wasn't able to find it. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10069] New: Error when installing openldap from brew on Macos Catalina
by openldap-its＠openldap.org 22 Jun '23

22 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10069 Issue ID: 10069 Summary: Error when installing openldap from brew on Macos Catalina Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: marianogedisman(a)gmail.com Target Milestone: --- Hello! I'm getting this error when installing from Homebrew on MacOS Catalina: ==> ./configure --prefix=/usr/local/Cellar/openldap/2.6.4 --sysconfdir=/usr/loca n==> make install Error: inreplace failed /usr/local/etc/openldap/slapd.conf: expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with #<Pathname:/usr/local/opt/openldap> /usr/local/etc/openldap/slapd.ldif: expected replacement of #<Pathname:/usr/local/Cellar/openldap/2.6.4> with #<Pathname:/usr/local/opt/openldap> -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 4066] Uniqueness overlay incorrectly checks for dupes with MODs outside of its seach base
by openldap-its＠openldap.org 19 Jun '23

19 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=4066 --- Comment #6 from knotmecute <kmcbacklink(a)gmail.com> --- https://knotmecute.com/ https://knotmecute.com/handmade/banjaran-collection/ https://knotmecute.com/handmade/mehfil-collection/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4066] Uniqueness overlay incorrectly checks for dupes with MODs outside of its seach base
by openldap-its＠openldap.org 19 Jun '23

19 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=4066 --- Comment #5 from knotmecute <kmcbacklink(a)gmail.com> --- Step into the vibrant world of Knotmecute's Banjaran collection, where exquisite bohemian jewelry takes center stage, inspired by tribal aesthetics and vibrant cultures. Our brand strives to revive the rich heritage art of tribes, incorporating abstract patterns and colorful mirror work into stunning pieces that make a bold and stylish statement. Crafted with meticulous precision and attention to detail, our luxury bohemian jewels are designed to complement a variety of occasions, from carefree beach travels to destination weddings. Each piece is thoughtfully created to evoke a sense of wanderlust and adventure, adding a touch of boho charm to your jewelry ensemble. The Banjara collection offers a wide range of accessories that cater to every woman's unique style and trending preferences. Whether you desire a statement necklace to elevate your evening attire or vibrant earrings to accentuate your beachy look, we have the perfect piece to fulfill your needs. Every jewelry piece in the Banjara collection is a work of art, meticulously handcrafted with vibrant colors, intricate mirror work, and captivating patterns. These colorful jewels go beyond being mere accessories—they carry a personalized touch, reflecting the essence of your vibrant spirit. Embrace the beauty of bohemian aesthetics with Knotmecute's Banjara brand. Discover our collection and adorn yourself with these stunning jewels that will turn heads wherever you go. Experience the joy of wearing luxurious, colorful bohemian jewelry that reflects your individuality and leaves a lasting impression. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10066] New: fsync -> fcntl(F_FULLFSYNC) on Apple platforms?
by openldap-its＠openldap.org 15 Jun '23

15 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10066 Issue ID: 10066 Summary: fsync -> fcntl(F_FULLFSYNC) on Apple platforms? Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: christophersauer(a)pacbell.net Target Milestone: --- Hi, Howard, I was thinking of adopting LMDB for a cross-platform project, but when quickly browsing the code, didn't see specializations for Apple platform' weakened fsync -> fcntl(F_FULLFSYNC). (Doc quick link, if useful: https://developer.apple.com/library/archive/documentation/System/Conceptual…) Should I be concerned? I think it's very likely that you're way ahead of me, but I just wanted to check in. (And couldn't otherwise find anything online about this.) Thanks so much for all you do! Chris -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10054] New: Value size limited to 2,147,479,552 bytes
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10054 Issue ID: 10054 Summary: Value size limited to 2,147,479,552 bytes Product: LMDB Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: louis(a)meilisearch.com Target Milestone: --- Hello, According to the documentation[0], a database that is not using `MDB_DUPSORT` can store values up to `0xffffffff` bytes (around 4GB). In practice, under Linux, the actual limit is `0x7ffff000` though (2^31 - 4096, so around 2GB). This is due to the write loop in `mdb_page_flush`. The `wsize` value determining how many bytes will be written can be as big as `4096*dp->mp_pages`[1], and the number of overflow pages grows with the size of the value put inside the DB. The `wsize` is not split in smaller chunks in the case where there are many overflow pages to write, and as a result the call to `pwrite`[2] does not perform a full write, but only a "short" write of 2147479552 bytes (the maximum allowed on a call to `pwrite` on Linux[3]). This would be OK if the short write condition was handled by looping and performing another `pwrite` with the rest of the data, but instead `EIO` is returned[4]. There seems to be a related, but different issue on macOS when trying to `pwrite` more the 2^31 bytes, that was already reported[5]. This issue was reported to me by a Meilisearch user because it causes their database indexing to fail[6]. I had to investigate a bit because their setup was peculiar (high number of documents in their database) and the `EIO` error code is not very descriptive of the underlying issue. I join a C reproducer of the issue that attempts to add a 2147479553 bytes value to the DB and fails with `EIO` (decreasing `nb_items` to a smaller value such as `2107479552` does succeed)[7]. Thank you for making LMDB! Louis Dureuil. [0]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/lmdb.h#LL284… [1]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#LL3770… [2]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3820 [3]: https://stackoverflow.com/questions/70368651/why-cant-linux-write-more-than… [4]: https://github.com/LMDB/lmdb/blob/mdb.master/libraries/liblmdb/mdb.c#L3840 [5]: https://bugs.openldap.org/show_bug.cgi?id=9736 [6]: https://github.com/meilisearch/meilisearch/issues/3654 [7]: https://github.com/dureuill/lmdb_3654/tree/main -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10062] New: How to store a data item of length greater than 511 in a dupsort db
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10062 Issue ID: 10062 Summary: How to store a data item of length greater than 511 in a dupsort db Product: LMDB Version: 0.9.30 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mega.alpha100(a)gmail.com Target Milestone: --- Is there a workaround to storing a data item with a length greater than the value of `fn mdb_env_get_maxkeysize()` or 511 in a dupsort db? Also, I tried to change the value of the `MDB_MAXKEYSIZE` macro but that led to an illegal instruction -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10050] New: Use of stack allocated string in mdb_strerror
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10050 Issue ID: 10050 Summary: Use of stack allocated string in mdb_strerror Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: es(a)m-labs.hk Target Milestone: --- https://git.openldap.org/openldap/openldap/-/blob/mdb.master/libraries/libl… This piece of code exists from 2014, and these lines are not working outside of MSVC. Moreover, they lead to segfaults in MINGW compiled environments. Please see the patch we use for potential fix: https://github.com/msys2/MINGW-packages/blob/31012dd33a32390d1e5f9b93388799… -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10061] New: Query on setting TLSVerifyClient option set to demand
by openldap-its＠openldap.org 12 Jun '23

12 Jun '23

https://bugs.openldap.org/show_bug.cgi?id=10061 Issue ID: 10061 Summary: Query on setting TLSVerifyClient option set to demand Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ramajay52(a)gmail.com Target Milestone: --- Dear Experts, In my case, I had set TLSVerifyClient to demand. I couldn't be able to establish a connection While providing TLSCACertificateFile alone. While setting the TLSVerifyClient option demand is it mandatory to provide the following option? 1. TLSCACertificateFile 2. TLSCertificateKeyFile 3. TLSCertificateFile Regards, Ram -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 25 May '23

25 May '23

https://bugs.openldap.org/show_bug.cgi?id=8447 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fixed in RE0.9: • 76bad923 by Howard Chu at 2023-05-25T19:33:44+00:00 ITS#8447 fix cursor_put(MDB_CURRENT) on DUPSORT DB with different-sized data -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9736] New: pwrite bug in OSX breaking LMDB promise about the maximum value size
by openldap-its＠openldap.org 22 May '23

22 May '23

https://bugs.openldap.org/show_bug.cgi?id=9736 Issue ID: 9736 Summary: pwrite bug in OSX breaking LMDB promise about the maximum value size Product: LMDB Version: unspecified Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hi, I was working with LMDB and found an issue when trying to write a value of approximately 3.3GiB in the database, I dive into the LMDB source code of the mdb_put method using the lldb debugger and found out that it was not related to an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS libc implementation. The pwrite function is given four parameters, the file descriptor, the buffer, the count of bytes to write from the buffer and, the offset of where to write it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits unsigned integer but when you call pwrite with a number bigger or equal to 2^31 it returns an error 22 (invalid argument). LMDB was returning a 22 error from the mdb_put call and not an EINVAL because the error was cause by an internal issue and not something catchable by LMDB. I am not sure about what we can do, can we implement this single pwrite [1] as multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like for Windows where we do specific things for this operating system too? I also found this issue on the RocksDB repository [2] about a similar problem they have with pwrite and write on Mac OS it seems. I understand that this is not a real promise that LMDB is specifying but rather an "in theory" rule [3]. Thank you for your time, kero [1]: https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/… [2]: https://github.com/facebook/rocksdb/issues/5169 [3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10055] New: EOS EOL
by openldap-its＠openldap.org 19 May '23

19 May '23

https://bugs.openldap.org/show_bug.cgi?id=10055 Issue ID: 10055 Summary: EOS EOL Product: OpenLDAP Version: 2.4.44 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: andrew.hudson(a)rtx.com Target Milestone: --- Hello, I work with Raytheon Intelligence and Space. I just have a quick question. I am in charge of keeping track of the software that is on my program's environment. We are on version 2.4.44. I am just wondering what the End of Support and the end of life of this version. Thank you very much. Andrew Hudson -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 15 May '23

15 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 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 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 15 May '23

15 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • f200ebd2 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Set javac source="8". • 578fba58 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Delete unused class Compare. JDK 1.5 removed the String.compareTo(Object) method so this class won't compile anymore, but luckily it's unused and can simply be deleted. • fa6c4c44 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Replace use of 'enum' as an identifier. Java 1.5 made 'enum' a keyword, which may not be used as an identifier. • 339120d5 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Replace use of deprecated class StringBufferInputStream. JDK 1.1 deprecated class StringBufferInputStream because it does not properly convert characters into bytes. • f494f56d by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Replace call to deprecated LDAPConnection.bind() method. JLDAP Sep_ndk_2003 deprecated LDAPConnection.bind(int, String, String) in favour of LDAPConnection.bind(int, String, byte[]). • 70b87f22 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Replace call to deprecated File.toURL() method. JDK 6 deprecated File.toURL() in favour of File.toURI().toURL() because it does not automatically escape characters that are illegal in URLs. • 44c3341b by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Add @Deprecated annotations to deprecated interface methods. JDK 1.5 deprecated these interface methods so they should be annotated as deprecated also in this implementation of that interface. • 25e88de0 by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Use full package name to disambiguate ambiguous reference. JDK 8 introduced java.util.Base64 which has the same class name as com.novell.ldap.util.Base64 which this code calls. • 762419dc by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Add java.sql interface methods introduced by JDK 6. • 8432fbfe by Fredrik Roubert at 2023-02-18T18:27:29+01:00 ITS#4501 Add java.sql interface methods introduced by JDK 7. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10053] New: liblber/idtest.c (and psap.h dependency) irrelevant to OpenLDAP
by openldap-its＠openldap.org 15 May '23

15 May '23

https://bugs.openldap.org/show_bug.cgi?id=10053 Issue ID: 10053 Summary: liblber/idtest.c (and psap.h dependency) irrelevant to OpenLDAP Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- configure.ac checks for psap.h presence, the only user being liblber's idtest.c - a test program that uses none of liblber API and claims to be part of ISODE X.500 code. I'm tempted to remove the configure check and the source file, letting that project adopt it if they still use it for something. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #10 from Shawn McKinney <smckinney(a)symas.com> --- (In reply to Fredrik Roubert from comment #9) > I never managed to find any documentation about what JAR files were needed, > so instead I used guesswork and Google to come up with this list on my own > for building with JDK 1.4.2: > > ant-1.7.0.jar > ant-junit-1.6.5.jar > ant-launcher-1.6.5.jar > jface-3.0.1.jar > junit-3.8.1.jar > novell-jldap-2013.08.30.1433-xplat.jar > swt-linux-gtk-3.0.1.jar > > I have no idea how correct that list might be, but at least it turned out to > be sufficent to make the build work. > > For building with JDK 8, the list becomes substantially smaller: > > jface-3.0.1.jar > novell-jldap-2013.08.30.1433-xplat.jar > swt-linux-gtk-3.0.1.jar Thanks, before I saw your reply, got it built with these (similar list): jldap-2009-10-07.jar junit-4.13.2.jar org.eclipse.jface-3.29.0.jar org.eclipse.swt.gtk.linux.x86_64-3.122.0.jar > > But I can't help wondering about JdbcLdapBrowserApp, whether that really is > something that is ever used by anyone anymore, for if it is not, you would > be able to simplify your codebase considerably by deleting all that source > code (and with that, the need for org.eclipse.swt and jfaces). Fortunately, these jars, other than jdbcldap, are recent, meaning they at least have no known CVE's outstanding? But, like you I'm left with the same thoughts. Who's using this, what parts can be sundowned, how do we test it, what to do next. -- Shawn -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #9 from Fredrik Roubert <fredrik(a)roubert.name> --- I never managed to find any documentation about what JAR files were needed, so instead I used guesswork and Google to come up with this list on my own for building with JDK 1.4.2: ant-1.7.0.jar ant-junit-1.6.5.jar ant-launcher-1.6.5.jar jface-3.0.1.jar junit-3.8.1.jar novell-jldap-2013.08.30.1433-xplat.jar swt-linux-gtk-3.0.1.jar I have no idea how correct that list might be, but at least it turned out to be sufficent to make the build work. For building with JDK 8, the list becomes substantially smaller: jface-3.0.1.jar novell-jldap-2013.08.30.1433-xplat.jar swt-linux-gtk-3.0.1.jar But I can't help wondering about JdbcLdapBrowserApp, whether that really is something that is ever used by anyone anymore, for if it is not, you would be able to simplify your codebase considerably by deleting all that source code (and with that, the need for org.eclipse.swt and jfaces). -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10052] New: ldapsearch error "can't contact LDAP Server" <1%
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=10052 Issue ID: 10052 Summary: ldapsearch error "can't contact LDAP Server" <1% Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: w3eagle(a)yahoo.com Target Milestone: --- version used: 2.4.44 that is from Amazon2 core OS: AWS Linux2 Details: Users reported occasional issues with AD server authentication with MicroStrategy. Open case with MicroStrategy and learnt then use openldap library for the AD authentication. We were able to reproduce the issue with ldapsearch like below. ldapsearch -H ldaps://$REMOTEHOST:$REMOTEPORT \ -x -D "CN=??????" \ -y pssd.txt -LLL \ -b "OU=???????" "(sAMAccountName=????)" dn We use crontab to query AD once every minute, and we were able to see a few issues each day, error rate is more than 1/1000 but less than 1/100. The error looks like below - ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) Not much info was logged other than this. We tried all kinds of stuff but it didn't help, eg. the ldap.conf settings to ignore certs validation, simplify the cert folder files etc. and the like. We think perhaps the TLS might be the issue, so we setup an nginx node within the same vpc, which communicates with AD server over TLS, but terminates TLS and talk to other ec2 with clear text. We were not able to see any errors. So we have proved, for some reason, then ldapsearch over ldaps fails with a low percentage. I previously reported case 10049, but it was closed. The message is like openldap is using other components for https/tls; so possibly bugs from other libraires. So to prove this issue is indeep on openldap, I schedule the same ldapsearch on the nginx box itself. Knowing nginx was using the same openssl library (openssl 1.0.2k), we reproduced the same, ~1% "can't contact LDAP server" error, on the nginx box. So this error is perhaps more related to openldap, or perhaps Cyrus SASL? (cyrus-sasl-lib 2.1.26). My question is whether this sounds like an openldap bug. Please advise. Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10051] New: ldapsearch error can't contact LDAP <1%
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=10051 Issue ID: 10051 Summary: ldapsearch error can't contact LDAP <1% Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: w3eagle(a)yahoo.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10049] New: ldapsearch can't contact LDAP
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=10049 Issue ID: 10049 Summary: ldapsearch can't contact LDAP Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: w3eagle(a)yahoo.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 10 May '23

10 May '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #8 from Shawn McKinney <smckinney(a)symas.com> --- I've setup a build env, using Java 8, apache ant 1.10, etc. Now, getting errors on missing dependencies, org.eclipse.swt.*, jfaces, ... I have not found instructions on openldap.org website how to build this. That's fine, certainly not something for this MR to address. But, before I go spend time chasing this down, are there steps written down? Doesn't have to be accurate, anything at all would help. Thanks -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10021] New: Cannot insert data into wiredtiger backend
by openldap-its＠openldap.org 27 Apr '23

27 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10021 Issue ID: 10021 Summary: Cannot insert data into wiredtiger backend Product: OpenLDAP Version: 2.6.4 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: jailbird(a)fdf.net Target Milestone: --- I have a test system running OpenLDAP 2.6.4 linked against WiredTiger 11.1.0 running on a RHEL9.1-based system. Running kernel is 6.1.16, filesystem is XFS. back_wt.la was added to cn=module and a simple olcDatabase=wt was created like: dn: olcDatabase=wt objectClass: olcDatabaseConfig objectClass: olcWtConfig olcDatabase: wt olcDbDirectory: /var/lib/ldap olcSuffix: dc=fdf,dc=net olcLimits: {0}dn.base="cn=root,dc=fdf,dc=net" time.soft=unlimited time.hard=u nlimited size.soft=unlimited size.hard=unlimited olcRootDN: cn=root,dc=fdf,dc=net olcWtConfig: create olcDbIndex: objectClass,uid,gidNumber,uidNumber pres,eq olcDbIndex: ou,cn,mail pres,eq,sub structuralObjectClass: olcWtConfig I start slapd and it creates the database files correctly. I then go and try to create the container with a simple .ldif and ldapadd: dn: dc=fdf,dc=net objectClass: dcObject objectClass: organization o: FDF dc: fdf That generates: [1677801597:758327][83158:0x55b4158fb640], file:dn2id.wt, WT_CURSOR.insert: [WT_VERB_DEFAULT][ERROR]: __wt_txn_id_check, 1339: write operations are not supported in read-committed or read-uncommitted transactions.: Operation not supported Mar 2 15:59:57 slapd[83158]: wt_dn2id_add: insert failed: Operation not supported (95) That comes from WiredTiger @ https://github.com/wiredtiger/wiredtiger/blob/5a032be765b1ebd9bb789e837cd00… but I don't seem to understand why it's happening on a simple add? Am I missing something obvious? -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9436] New: OpenSSL 3.0: libldap uses depreciated functions
by openldap-its＠openldap.org 27 Apr '23

27 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=9436 Issue ID: 9436 Summary: OpenSSL 3.0: libldap uses depreciated functions Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated" is specified. Currently hitting these errors: ./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate' ./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams' ./.libs/libldap.so: undefined reference to `ERR_get_error_line' ./.libs/libldap.so: undefined reference to `DH_free' ./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh' Notes: SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0 SSL_CTX_set_tmp_dh should be replaced as follows: # define SSL_CTX_set_tmp_dh(ctx,dh) \ SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh)) Have to dig deeper for: PEM_read_bio_DHparams ERR_get_error_line DH_free -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 10036] New: ldapsearch to support IPv6 addresses in session tracking control
by openldap-its＠openldap.org 27 Apr '23

27 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10036 Issue ID: 10036 Summary: ldapsearch to support IPv6 addresses in session tracking control Product: OpenLDAP Version: 2.6.4 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: vantaa(a)outlook.com Target Milestone: --- When ldapsearch is told to include the session tracking control (-e sessiontracking), it gets the local IP address via gethostbyname() which is IPv4 only. Probably it should use getaddrinfo() which is IPv6 capable. The source code is in clients/tools/common.c:st_value(). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 24 Apr '23

24 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=8958 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9993 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 24 Apr '23

24 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=8958 --- Comment #43 from Quanah Gibson-Mount <quanah(a)openldap.org> --- ldap_pvt_thread_pool_pausequery does not exist in RE25, which is why this is a 2.6 or later only fix. (for future reference and why the fix was reverted from RE25) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10043] New: LMDB Wont Run in MacOS Sandbox
by openldap-its＠openldap.org 24 Apr '23

24 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10043 Issue ID: 10043 Summary: LMDB Wont Run in MacOS Sandbox Product: LMDB Version: 0.9.30 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: t(a)tannersilva.com Target Milestone: --- Howdy from Texas. I am the developer of QuickLMDB, the high performance wrapper for Swift. I have been building an lmdb-based nostr client for the CakeWallet team using my wrapper. I initially began writing this app with a wide deployment target (iOS and MacOS with Sandboxing enabled). To my surprise, I was unable to get QuickLMDB running on MacOS with its sandboxing mode enabled. It simply wouldn't run. I didn't allow myself to get too caught up in that particular issue on my project (we have dropped MacOS from our initial targets for other reasons anyways), however, I've since had a user raise an issue on my GitHub describing the exact issue I dealt with in breaking ground on the nostr client with its "new project defaults" build settings in Xcode. https://github.com/tannerdsilva/QuickLMDB/issues/1 https://github.com/agisboye/SwiftLMDB/issues/23 Admittedly, I haven't been able to thoroughly investigate this issue beyond my own brief experiences with it in my mostly blank project. Between the two links above, the users of the Swift wrappers seem to have tested this issue in a more diverse way than I would do initially anyways. In search of duplicate issues, I was unable to find anything that clearly draws a line around sandboxing on MacOS, which is the primary concern here. Confirmed by my own experiences: the issue here is simply that LMDB seems to be impossible to run in a MacOS sandbox. When sandboxing is disabled, LMDB behaves exactly as I would expect. Apple Silicon - macOS 13.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9832] New: back-monitor crash when sizelimit in operation
by openldap-its＠openldap.org 20 Apr '23

20 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=9832 Issue ID: 9832 Summary: back-monitor crash when sizelimit in operation Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If a back-monitor search gets a failure in send_search_entry(), e.g. due to sizelimit being reached, a pending server pause, etc., it will try to call monitor_cache_release( mi, e ) where e == NULL instead of the correct entry to release. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10034] New: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()"
by openldap-its＠openldap.org 17 Apr '23

17 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10034 Issue ID: 10034 Summary: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" Product: LMDB Version: 0.9.23 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: 763280032(a)qq.com Target Milestone: --- We found that when lmdb is opened after OS startup and data is written to it, lmdb will trigger abort probabilistically(Restart the OS 600 times will trigger once); We want to know what situation triggers this issue(Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()); we want to know if there is a problem with our usage; Please Help Us (gdb) x/8s 0x8baee988 0x8baee988: "8\373Բ\b\371Բmdb.c:5542: Assertion 'i < NUMKEYS(mp)' failed in mdb_page_search_root()" -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 10038] New: connections_destroy: nothing to destroy
by openldap-its＠openldap.org 17 Apr '23

17 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10038 Issue ID: 10038 Summary: connections_destroy: nothing to destroy Product: OpenLDAP Version: 2.5.13 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: rasagollaravi(a)gmail.com Target Milestone: --- Hello Team, I have installed openldap 2.5.13 version and trying to start ldap getting below message. log message: connections_destroy: nothing to destroy Thanks, Ravi kumar 97171585372 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9460] New: Drop support for OpenSSL older than 1.1.1
by openldap-its＠openldap.org 11 Apr '23

11 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=9460 Issue ID: 9460 Summary: Drop support for OpenSSL older than 1.1.1 Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- OpenSSL no longer supports the 1.0.2 series and specifically notes it should not be used: "All older versions (including 1.1.0, 1.0.2, 1.0.0 and 0.9.8) are now out of support and should not be used." Currently configure checks for 1.0.2 or higher. OpenSSL 1.1.1 is supported through 11 Sep 2023. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10040] New: ENGLISH-SPEAKING WITH OXFORD SCHOOL OF ENGLISH IN DELHI
by openldap-its＠openldap.org 10 Apr '23

10 Apr '23

https://bugs.openldap.org/show_bug.cgi?id=10040 Issue ID: 10040 Summary: ENGLISH-SPEAKING WITH OXFORD SCHOOL OF ENGLISH IN DELHI Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: oxfordschoolofenglishdelhi(a)gmail.com Target Milestone: --- Created attachment 959 --> https://bugs.openldap.org/attachment.cgi?id=959&action=edit Best English Speaking Institute Delhi LEARN ENGLISH-SPEAKING WITH OXFORD SCHOOL OF ENGLISH IN DELHI Oxford School of English- the Best Spoken English Institute in Delhi - is the flagship offshoot of Hindustan Soft Education Ltd which is an NSDC Grade-A partner company, and Certified Silver training partner of Cambridge University Press. In the last 25 years, through our spoken English classes, we have successfully trained more than 90,000 students. With Cambridge Interchange Courses from Cambridge University Press combined with audio-video Ed-tech, and scores of classroom activities like Role Plays and skits, our experienced trainers deliver an indelible learning experience at our centres located within easy reach of metro stations. Our Specialties ------------------------------- ---------- Best English-Speaking Institute in Delhi since 1997 Six own centres with best of class infrastructure Certified Silver Partner of Cambridge University Press Insightfully crafted Cambridge English courses - English speaking course for beginners, Intermediate English course, Advanced English-speaking course, Personal English Coaching classes, English classes for competitive exams, IELTS Audio-video, PDF worksheets, Blog, Forum on Cambridge Learning Management System (CLMS) In-house online Learning Management System (LMS) Experienced and friendly trainers Activity-oriented training sessions For More Details:-- Whatsapp: +911145680574 Mobile: 91+ 9667462832 https://www.oxfordschoolofenglish.in/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8977] Make IDL sizes configurable in back-mdb
by openldap-its＠openldap.org 28 Mar '23

28 Mar '23

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

1 0

[Issue 10027] New: MDB_TXN_FULL on large write transactions
by openldap-its＠openldap.org 28 Mar '23

28 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10027 Issue ID: 10027 Summary: MDB_TXN_FULL on large write transactions Product: LMDB Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: renault.cle(a)gmail.com Target Milestone: --- Hello, Our users ([1], [2]) encountered MDB_TXN_FULL errors when our Meilisearch engine processed a large write transaction. We did read the documentation about this error in the codebase of LMDB: Spill pages from the dirty list back to disk. This is intended to prevent running into #MDB_TXN_FULL situations, but note that they may still occur in a few cases: 1) our estimate of the txn size could be too small. Currently this seems unlikely, except with a large number of #MDB_MULTIPLE items. 2) child txns may run out of space if their parents dirtied a lot of pages and never spilled them. TODO: we probably should do a preemptive spill during #mdb_txn_begin() of a child txn, if the parent's dirty_room is below a given threshold. Otherwise, if not using nested txns, it is expected that apps will not run into #MDB_TXN_FULL any more. The pages are flushed to disk the same way as for a txn commit, e.g. their P_DIRTY flag is cleared. If the txn never references them again, they can be left alone. If the txn only reads them, they can be used without any fuss. If the txn writes them again, they can be dirtied immediately without going thru all of the work of #mdb_page_touch(). Such references are handled by #mdb_page_unspill(). However, It looks like we are not in those scenarios, we are not using MDB_DUPFIXED, and we are not using sub-transactions. We don't use the MDB_VL32 flag either, so this is not related to [3]. Thank you for your time, Have a nice day 💡 [1]: https://github.com/meilisearch/meilisearch/issues/3603 [2]: https://github.com/meilisearch/meilisearch/issues/3349 [3]: https://bugs.openldap.org/show_bug.cgi?id=8813 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 10029] New: slapd crashes when run with unlimited open files
by openldap-its＠openldap.org 27 Mar '23

27 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10029 Issue ID: 10029 Summary: slapd crashes when run with unlimited open files Product: OpenLDAP Version: 2.6.4 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gray(a)nxg.name Target Milestone: --- To reproduce: % ulimit -n unlimited % $T/openldap-2.6.4/libexec/slapd -d-1 641ee8bc.32f05820 0x1dc760140 @(#) $OpenLDAP: slapd 2.6.4 (Mar 25 2023 12:25:49) $ openldap 641ee8bc.32f39ff8 0x1dc760140 daemon_init: <null> 641ee8bc.32f40588 0x1dc760140 daemon: SLAP_SOCK_INIT: dtblsize=-1 641ee8bc.32f43080 0x1dc760140 ch_calloc of 1 elems of 18446744073709551615 bytes failed Assertion failed: (0), function ch_calloc, file ch_malloc.c, line 107. zsh: abort $T/openldap-2.6.4/libexec/slapd -d-1 This is because `daemon.c` (line 1867) uses the maximum number of open files to set `dtblsize`, which is subsequently used to size an array: 1867 #ifdef HAVE_SYSCONF 1868 dtblsize = sysconf( _SC_OPEN_MAX ); 1869 #elif defined(HAVE_GETDTABLESIZE) 1870 dtblsize = getdtablesize(); 1871 #else /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */ 1872 dtblsize = FD_SETSIZE; 1873 #endif /* ! HAVE_SYSCONF && ! HAVE_GETDTABLESIZE */ If the maximum number of FDs is unlimited, then sysconf(_SC_OPEN_MAX) returns -1, and the program crashes when it tries to malloc that much memory. I've marked this as OS=macOS because that's what I'm illustrating this on, but the same thing would happen on any OS where the sysconf call returns a negative number for the 'unlimited' case. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10022] New: OlcAccess (META)
by openldap-its＠openldap.org 27 Mar '23

27 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10022 Issue ID: 10022 Summary: OlcAccess (META) Product: OpenLDAP Version: 2.5.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: bourguijl(a)gmail.com Target Milestone: --- Dears, I've configured a META ldap instance pointing to a LDAP backend. In this backend, there are a few ACLs but which ones don't restrict ldapsearch that I perform from the META frontend. I just have an issue when I set some ACLs on the META frontend and more specially when I insert attrs=xxx in the ACL. ACL = OK {0}to dn.one="ou=staff,o=mobistar.be" by dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read ACL NOT OK {0}to dn.one="ou=staff,o=mobistar.be" attrs=uid by dn="uid=a0621004,ou=ObeExternalITOnGcp,ou=partners,o=mobistar.be" read Can you explain why when I restrict to an attribute, my ldapsearch didn't provide me any response as expected ? Is it a bug ? Thx in advance, J-L. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 27 Mar '23

27 Mar '23

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

1 0

[Issue 9496] New: Some writes missing from database
by openldap-its＠openldap.org 15 Mar '23

15 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=9496 Issue ID: 9496 Summary: Some writes missing from database Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: igfoo(a)github.com Target Milestone: --- With the attached test program, some of my database writes appear not to actually be written to the database. For example, a run may look like this: $ ./run.sh All done. All finished 1802 test.txt foo_200 is missing bar_200 is missing foo_404 is missing bar_404 is missing foo_407 is missing bar_407 is missing The script that I am using to run the program is below. This is using mdb.master 52bc29ee2efccf09c650598635cd42a50b6ecffe on Linux, with an ext4 filesystem. Is this an LMDB bug, or is there a bug in my code? Thanks Ian #!/bin/sh set -e if ! [ -d lmdb ] then rm -rf lmdb git clone https://github.com/LMDB/lmdb.git INSTALL_DIR="`pwd`/inst" cd lmdb/libraries/liblmdb make install prefix="$INSTALL_DIR" cd ../../.. fi gcc -Wall -Werror -Iinst/include loop.c inst/lib/liblmdb.a -o loop -pthread rm -f test.db test.db-lock ./loop echo "All finished" mdb_dump -np test.db > test.txt wc -l test.txt for i in `seq 100 999` do if ! grep -q "foo_$i" test.txt then echo "foo_$i is missing" fi if ! grep -q "bar_$i" test.txt then echo "bar_$i is missing" fi done -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 10017] New: ldap.conf setting "BINDDN" has no associated LDAP_OPT_XXX constant for ldap_get_opt ldap_set_opt
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10017 Issue ID: 10017 Summary: ldap.conf setting "BINDDN" has no associated LDAP_OPT_XXX constant for ldap_get_opt ldap_set_opt 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: --- The Configuration file setting "BINDDN" has no associated LDAP_OPT_XXX constant and is not exposed to the ldap_get_opt / ldap_set_opt API. This is the only option that is not so accessible and this seems like an oversight. Option "PORT" is also not exposed but that is deprecated. You could make the case it shouldn't be. This setting could obviously be of interest to the Application and I see no reason for it to be hidden. Simple applications / tools may not have their own configuration files and instead rely solely of the ldap.conf file to configure openldap. Such an application could not easy supply a DN to the "bind" calls but may still wish to know the value specified in the configuration file. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 10019] New: dynlist's +memberOf attribute not searchable/fetchable with anonymous binds
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10019 Issue ID: 10019 Summary: dynlist's +memberOf attribute not searchable/fetchable with anonymous binds Product: OpenLDAP Version: 2.5.13 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: msl(a)touk.pl Target Milestone: --- Hi, This is and issue we discovered (as a side effect of testing) after switching from memberof overlay to dynlist with our confluence directory setup - which previously worked fine, but not anymore. Side effect of testing - as judging from the logs it seems that confluence is doing normal binds (which is even stranger as non-anonymous bind ldapsearch from commandline works correctly). Anyway, consider the following setup: groupOfURLs labeledURI uniqueMember+memberOf@groupOfUniqueNames We only use static groups, so the following group with one of members: DN: cn=TouK,ou=TouK,ou=Group,dc=touk,dc=pl objectClass: groupOfUniqueNames ... uniqueMember: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl Correlates to: DN: cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl ... memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl The initial ACLs are set as follows: {0}to * by dn=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break {1}to dn.subtree=ou=People,dc=touk,dc=pl attrs=entry,entryUUID,memberOf,@toukAnonAccess by anonymous =scr by * break {2}to dn.subtree=ou=Group,dc=touk,dc=pl attrs=entry,@groupOfUniqueNames,@groupOfNames by anonymous =scr by * break ... later ACLs handling specific accesses and stuff, terminated with: {14}to * by users =scr Now if we do search doing non-anonymous binds, everything works correctly: ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=Michał Sołtys,ou=Touki,ou=People,dc=touk,dc=pl" -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -y ./pass -LLL -v '(uid=ast)' memberOf entryUUID ldap_initialize( ldaps://ldap.touk.pl:636/??base ) filter: (uid=ast) requesting: memberOf entryUUID dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2 memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl But if we do an anonymous search - with ACLs as above explicitly allowing access to all relevant parts as in rule {1}, memberOf is not returned (it can't be used in filtering either): ldapsearch -x -H ldaps://ldap.touk.pl -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(uid=ast)' memberOf entryUUID ldap_initialize( ldaps://ldap.touk.pl:636/??base ) filter: (uid=ast) requesting: memberOf entryUUID dn: cn=Adam Stus,ou=Touki,ou=People,dc=touk,dc=pl entryUUID: 6c1adf48-a800-103a-8044-3100241d53c2 This - unless I missed something - looks like a bug. As mentioned above - our local confluence install is using dedicated user, but for some reason it is also unable filter using memberOf (though surprisingly it does work from command line for non-anonymous bind). Relevant parts of the slapd.log of such query: Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128 Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256 Mar 6 19:21:24 lipa1 slapd[1206591]: conn=1009 op=0 RESULT tag=97 err=0 qtime=0.000016 etime=0.000230 text= ... other operations Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3 filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))" Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SRCH attr=1.1 Mar 6 19:26:58 lipa1 slapd[1206591]: conn=1009 op=28 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.000541 nentries=0 text= See (nentries=0) above - but identical search performed from command line, e.g.: ldapsearch -x -H ldaps://ldap.touk.pl -D "cn=confluence,ou=Apps,dc=touk,dc=pl" -y ./b -a always -s sub -b 'ou=Touki,ou=People,dc=touk,dc=pl' -o ldif-wrap=no -LLL -v '(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))' 1.1 correctly returns 6 people: Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" method=128 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 BIND dn="cn=confluence,ou=Apps,dc=touk,dc=pl" mech=SIMPLE bind_ssf=0 ssf=256 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=0 RESULT tag=97 err=0 qtime=0.000025 etime=0.000269 text= Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH base="ou=Touki,ou=People,dc=touk,dc=pl" scope=2 deref=3 filter="(&(toukAccountActive=TRUE)(memberOf=cn=finanse,ou=touk,ou=group,dc=touk,dc=pl))" Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SRCH attr=1.1 Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=2 UNBIND Mar 7 15:21:31 lipa1 slapd[1220021]: conn=26424 op=1 SEARCH RESULT tag=101 err=0 qtime=0.000019 etime=0.002765 nentries=6 text= -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

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

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Fredrik Roubert from comment #6) > Does anyone have any opinion about this? We've assigned it for review, ty for the PR! -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

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

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 13 Mar '23

13 Mar '23

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

1 0

[Issue 4501] jdbcldap: use of enum reserved work (Java 1.5)
by openldap-its＠openldap.org 11 Mar '23

11 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=4501 --- Comment #6 from Fredrik Roubert <fredrik(a)roubert.name> --- Does anyone have any opinion about this? -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10018] New: lmdb runs for two years and triggers abort error
by openldap-its＠openldap.org 09 Mar '23

09 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=10018 Issue ID: 10018 Summary: lmdb runs for two years and triggers abort error Product: LMDB Version: 0.9.23 Hardware: Other OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: Zhou.chang(a)h3c.com Target Milestone: --- We found that when the Last transaction ID exceeds the maximum value, the database abort signal will be triggered and two errors will be reported： Assertion 'rc == 0' failed in mdb_page_dirty() Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch() I would like to ask whether the current lmdb has considered this situation, ./mdb_stat -e /tmp/lmdb Environment Info Map address: (nil) Map size: 10485760 Page size: 4096 Max pages: 2560 Number of pages used: 238 Last transaction ID: 4294967295 Max readers: 126 Number of readers used: 2 -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 06 Mar '23

06 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=8447 --- Comment #5 from Howard Chu <hyc(a)openldap.org> --- Created attachment 951 --> https://bugs.openldap.org/attachment.cgi?id=951&action=edit test case Simple reproducer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 06 Mar '23

06 Mar '23

https://bugs.openldap.org/show_bug.cgi?id=8447 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |TEST --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- Fixed in mdb.master c7b3cc4df6dfe8f0772fb509bdc74777667caa43 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 10007] New: lmdb does not work on MSYS2/Cygwin
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10007 Issue ID: 10007 Summary: lmdb does not work on MSYS2/Cygwin Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: facboy(a)gmail.com Target Milestone: --- lmdb can be compiled if the correct flags are set on MSYS2/Cygwin, but it does not actually work. `make test` will result in errors. If `make CPPFLAGS="-DMDB_USE_ROBUST=0"` is used, `mtest` fails with: > mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): Invalid argument > Aborted (core dumped) If `make CPPFLAGS="-DMDB_USE_POSIX_SEM=1"` is used, `mtest` fails with: > mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): No such file or directory > Aborted (core dumped) -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9972] New: SSS needs READ instead of SEARCH access
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=9972 Issue ID: 9972 Summary: SSS needs READ instead of SEARCH access Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have configured an OpenLDAP 2.6 server with dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * search # no problem if this is READ olcAccess: to dn.sub="dc=aegee,dc=org" by * read … dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config objectClass:olcOverlayConfig The content of the tree is available anymously by calling ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub . When I modify the call to use SSS: ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 it also returns results, but ends with ``` # search result search: 93 result: 50 Insufficient access # numResponses: 3 # numEntries: 2 ``` When I modify above: olcAccess: to dn="cn=bodies,dc=aegee,dc=org" by * read then the access is sufficient. There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub` does not return it. These work without a problem: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E sss=ou:2.5.13.15 ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one This produces Insufficient access: ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E sss=ou:2.5.13.15 That said client-side-sorting does work without a problem, but server-side sorting requires not only SEARCH, but also READ privileges on dn="cn=bodies,dc=aegee,dc=org". I find this is a bug: SSS requires read-acesss to data, which is not supposed to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the additional server-side sorting no additional privileges shall be required, compared to returning the results without server-side-sorting. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 10009] New: test076 execution failed
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10009 Issue ID: 10009 Summary: test076 execution failed Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: 1010881517(a)qq.com Target Milestone: --- openldap-2.6.3test case test076-authid-rewrite failed when I upgrade openssl to openssl3.0 Does anyone have a similar problem? >>>>> 00:27:30 Starting test076-authid-rewrite for mdb... running defines.sh Starting slapd on TCP/IP port 9011... /home/abuild/rpmbuild/BUILD/openldap-2.6.3/openldap-2.6.3/tests Using ldapsearch to check that slapd is running... Checking whether DIGEST-MD5 is supported... Adding schema and database... Using ldapadd to populate the database... Adding olcAuthzRegexp rule for static mapping... Testing ldapwhoami as Manager... ./scripts/test076-authid-rewrite: line 177: 219330 Segmentation fault (core dumped) $LDAPSASLWHOAMI -H $URI1 -Y $MECH -U $ID -w $PASSWD ldapwhoami failed (139)! >>>>> 00:27:33 Failed test076-authid-rewrite for mdb after 3 seconds (exit 139) -- You are receiving this mail because: You are on the CC list for the issue.

2 9

[Issue 10012] New: fcntl called without checking value
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10012 Issue ID: 10012 Summary: fcntl called without checking value Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: balaev(a)tarantool.org Target Milestone: --- Created attachment 949 --> https://bugs.openldap.org/attachment.cgi?id=949&action=edit patch file ldap_pvt_socket() and ldap_int_socket() calls fcntl without checking value of file descriptor. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 10008] New: Makefile does not building DLLs on Cygwin/MSYS2
by openldap-its＠openldap.org 27 Feb '23

27 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=10008 Issue ID: 10008 Summary: Makefile does not building DLLs on Cygwin/MSYS2 Product: LMDB Version: unspecified Hardware: All OS: Windows Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: facboy(a)gmail.com Target Milestone: --- Currently when building on Cygwin/MSYS2 make does not generate DLL files. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8447] LMDB: Overwriting values in MDB_DUPSORT databases broken
by openldap-its＠openldap.org 24 Feb '23

24 Feb '23

https://bugs.openldap.org/show_bug.cgi?id=8447 --- Comment #3 from nicolas.werner(a)hotmail.de --- I can reproduce this without using any cursors. I am using the lmdb++ header for simplicity (https://github.com/hoytech/lmdbxx), but it also reproduces using the plain C API. Full repro: #include <iostream> #include <stdlib.h> #include "lmdb++.h" #define PROJECT_NAME "mdb-dup-bug" static int compare_state_key(const MDB_val *a, const MDB_val *b) { auto get_skey = [](const MDB_val *v) { std::string_view data(static_cast<const char *>(v->mv_data), v->mv_size); return data.substr(0, data.find(',')); }; return get_skey(a).compare(get_skey(b)); } int main(int argc, char **argv) { if(argc != 1) { std::cout << argv[0] << "takes no arguments.\n"; return 1; } std::cout << "This is project " << PROJECT_NAME << ".\n"; auto env = lmdb::env::create(); env.set_max_dbs(10); char dirname[] = "/tmp/lmdb-bug.XXXXXX"; env.open(mkdtemp(dirname)); lmdb::dbi db; { auto txn = lmdb::txn::begin(env); db = lmdb::dbi::open( txn, std::string("dupsort").c_str(), MDB_CREATE | MDB_DUPSORT); lmdb::dbi_set_dupsort(txn, db, compare_state_key); db.put(txn, "abcd", "ab,cdef"); db.put(txn, "abcd", "a,abc"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 5, data: '" << data << "', expected: 'a,abc'\n"; txn.commit(); } { auto txn = lmdb::txn::begin(env); db.put(txn, "abcd", "a,12"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 4, data: '" << data << "', expected: 'a,12'\n"; txn.commit(); } { auto txn = lmdb::txn::begin(env); db.put(txn, "abcd", "a,x"); txn.commit(); } { auto txn = lmdb::txn::begin(env); std::string_view data; db.get(txn, "abcd", data); std::cout << "Data size: " << data.size() << " expected: 3, data: '" << data << "', expected: 'a,x'\n"; txn.commit(); } return 0; } This prints the following output: This is project mdb-dup-bug. Data size: 5 expected: 5, data: 'a,abc', expected: 'a,abc' Data size: 5 expected: 4, data: 'a,12c', expected: 'a,12' Data size: 5 expected: 3, data: 'a,x2c', expected: 'a,x' Commenting out the first put with the different data-key resolves the issue, but certainly you would expect that replacing a duplicate replaces the size too. Doing explicit delete before the put works around this issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs