- 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 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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs