openldap-bugs

openldap-bugs@openldap.org

1 participants
20891 discussions

[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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs