openldap-bugs March 2022

openldap-bugs@openldap.org

1 participants
115 discussions

[Issue 9811] New: slapadd silently fails when importing ldif file including another one
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9811 Issue ID: 9811 Summary: slapadd silently fails when importing ldif file including another one Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- This issue is about openldap 2.5.11. (not tested on 2.6) When importing a new configuration from an ldif file, for example by this command: slapadd -n0 -F /usr/local/openldap/etc/openldap/slapd.d -l /var/backups/openldap/config-00000000000000.ldif the command answers by a 0 result code but the cn=config database is not fully imported. Also there is no special message displayed. The complete config-00000000000000.ldif file is below. The problem is in the custom.ldif included from config-00000000000000.ldif For example, the problem appears if the custom.ldif is this one: ``` # Custom ldif schema ``` or if the custom.ldif is that one (with an end-of-line at the end): ``` # Custom ldif schema dn: cn=custom,cn=schema,cn=config objectClass: olcSchemaConfig cn: custom ``` The expected behaviour should be to return an error code, and to display the corresponding message on stdout. Here is the full config-00000000000000.ldif file: ``` dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: slapd.conf olcConfigDir: slapd.d olcArgsFile: /usr/local/openldap/var/run/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcListenerThreads: 1 olcLocalSSF: 71 olcPidFile: /usr/local/openldap/var/run/slapd.pid olcReadOnly: FALSE olcSaslHost: 127.0.0.1 olcSaslSecProps: none olcServerID: 1 olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificateFile: /etc/ssl/certs/ca-certificates.crt olcTLSCertificateFile: /etc/ssl/certs/ssl-cert-snakeoil.pem olcTLSCertificateKeyFile: /etc/ssl/private/ssl-cert-snakeoil.key olcTLSCRLCheck: none olcTLSVerifyClient: allow olcTLSProtocolMin: 3.3 olcToolThreads: 1 olcWriteTimeout: 0 olcLogLevel: stats dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/local/openldap/lib64/:/usr/local/openldap/libexec/openldap/ olcModuleLoad: argon2.la olcModuleLoad: pw-pbkdf2.la olcModuleLoad: back_mdb.la olcModuleLoad: dynlist.la olcModuleLoad: ppolicy.la olcModuleLoad: syncprov.la olcModuleLoad: unique.la olcModuleLoad: refint.la dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///usr/local/openldap/etc/openldap/schema/core.ldif include: file:///usr/local/openldap/etc/openldap/schema/cosine.ldif include: file:///usr/local/openldap/etc/openldap/schema/nis.ldif include: file:///usr/local/openldap/etc/openldap/schema/inetorgperson.ldif include: file:///usr/local/openldap/etc/openldap/schema/dyngroup.ldif include: file:///usr/local/openldap/etc/openldap/schema/custom.ldif dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: {-1}frontend olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: to dn.base="" by * read olcAccess: to dn.base="cn=Subschema" by * read olcAccess: to * by self write by users read by anonymous auth olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSecurity: ssf=128 olcSizeLimit: 500 olcSyncUseSubentry: FALSE olcMonitoring: FALSE olcPasswordHash: {ARGON2} olcSortVals: member dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=config olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$eBzdIP+Zv/H/TmAw0xTXOg$JNQR9asBjEX5XYcTuqygvIY5S3iH43uqaqWQa9e0jNU olcSyncUseSubentry: FALSE olcMonitoring: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {1}mdb olcDbDirectory: /usr/local/openldap/var/openldap-data olcSuffix: dc=my-organization,dc=com olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,dc=my-organization,dc=com olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$22H7iUTEuPMmwYnLr07PjQ$257rNncoS6L/k4HUXmROU7p2SfinVjfjFeUz4pK8gEw olcSyncUseSubentry: FALSE olcLastBind: TRUE olcMonitoring: TRUE olcDbIndex: objectClass eq olcDbIndex: entryUUID eq olcDbIndex: entryCSN eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbMaxSize: 4294967296 dn: olcOverlay={0}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov olcSpCheckpoint: 100 10 olcSpSessionlog: 100 dn: olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=default,ou=ppolicies,dc=my-organization,dc=com olcPPolicyHashCleartext: TRUE olcPPolicyUseLockout: TRUE dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {2}refint olcRefintAttribute: member olcRefintNothing: cn=nothing,dc=my-organization,dc=com dn: olcOverlay={3}dynlist,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcDynamicList olcOverlay: {3}dynlist olcDlAttrSet: groupOfURLs memberURL member+memberOf@groupOfNames* dn: olcDatabase={2}monitor,cn=config objectClass: olcDatabaseConfig olcDatabase: {2}monitor olcRootDN: cn=monitor olcRootPW: {ARGON2}$argon2id$v=19$m=65536,t=2,p=1$f1aoIjM0CjWwGIyBAsjzyw$j+1bYxs+CYOPR2lXrvamB7yFzSX/nNMiVwIn7vwPRVw olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcSyncUseSubentry: FALSE olcMonitoring: FALSE ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9803] New: liblber: assertion( ber->ber_buf == NULL ); failed
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9803 Issue ID: 9803 Summary: liblber: assertion( ber->ber_buf == NULL ); failed Product: OpenLDAP Version: 2.4.46 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: jengelh(a)inai.de Target Milestone: --- libraries/liblber/io.c function ber_get_next contains a line assert( ber->ber_buf == NULL ); and with a larger application that uses libldap-2.4.46, I am running into that sporadically. I have no idea how that happens, but it seems probable the LDAP server (of which there is also no info on) is sending something that is interpreted as invalid and ber_buf does not get freed, so it's set on the next invocation. ``` (gdb) zcore: io.c:514: ber_get_next: Assertion `ber->ber_buf == NULL' failed. Thread 40 "rpc/34" received signal SIGABRT, Aborted. [Switching to Thread 0x7fffd6ff8700 (LWP 18485)] (gdb) up #1 0x00007ffff20fb585 in abort () from /lib64/libc.so.6 (gdb) #2 0x00007ffff20f285a in __assert_fail_base () from /lib64/libc.so.6 (gdb) #3 0x00007ffff20f28d2 in __assert_fail () from /lib64/libc.so.6 (gdb) #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) p ber $1 = (BerElement *) 0x6070000b0360 (gdb) p *ber $2 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) up #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) #7 ldap_result (ld=ld@entry=0x6040000aa610, msgid=<optimized out>, all=all@entry=1, timeout=timeout@entry=0x0, result=result@entry=0x7fffd6ff6348) at result.c:120 120 rc = wait4msg( ld, msgid, all, timeout, result ); (gdb) p result $3 = (LDAPMessage **) 0x7fffd6ff6348 (gdb) p result[0] $4 = (LDAPMessage *) 0x0 (gdb) dow #6 wait4msg (result=0x7fffd6ff6348, timeout=<optimized out>, all=1, msgid=<optimized out>, ld=0x6040000aa610) at result.c:365 365 rc = try_read1msg( ld, msgid, all, lc, result ); (gdb) dow #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p ber $5 = <optimized out> (gdb) dow #4 0x00007fffee0f48a1 in ber_get_next (sb=0x6040000aa650, len=len@entry=0x7fffd6ff61c8, ber=ber@entry=0x6070000b0360) at io.c:514 514 assert( ber->ber_buf == NULL ); (gdb) l 509 * 510 * We expect tag and len to be at most 32 bits wide. 511 */ 512 513 if (ber->ber_rwptr == NULL) { 514 assert( ber->ber_buf == NULL ); 515 ber->ber_rwptr = (char *) &ber->ber_len-1; 516 ber->ber_ptr = ber->ber_rwptr; 517 ber->ber_tag = 0; 518 } (gdb) p ber $6 = (BerElement *) 0x6070000b0360 (gdb) p ber[0] $7 = {ber_opts = {lbo_valid = 2, lbo_options = 1, lbo_debug = 0}, ber_tag = 116, ber_len = 78, ber_usertag = 0, ber_buf = 0x6070000b03d0 "cP", ber_ptr = 0x6070000b03d0 "cP", ber_end = 0x6070000b041e "", ber_sos_ptr = 0x0, ber_rwptr = 0x0, ber_memctx = 0x0} (gdb) p ber->ber_buf $8 = 0x6070000b03d0 "cP" (gdb) up #5 0x00007fffee310c91 in try_read1msg (result=0x7fffd6ff6348, lc=0x6080001182a0, all=1, msgid=18, ld=0x6040000aa610) at result.c:494 494 tag = ber_get_next( lc->lconn_sb, &len, ber ); (gdb) p len $10 = 99 (gdb) p lc $11 = (LDAPConn *) 0x6080001182a0 ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9802] New: Segfault while changing configuration in OpenLDAP 2.6.1
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9802 Issue ID: 9802 Summary: Segfault while changing configuration in OpenLDAP 2.6.1 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: manuel.flury(a)gmail.com Target Milestone: --- Created attachment 878 --> https://bugs.openldap.org/attachment.cgi?id=878&action=edit GDB traces and olcConfig Dear all, I am trying to configure back_meta for testing virtual directory. Attached is my config. It may not make sense. Trying to change configuration under olcMetaSub={0}uri,olcDatabase={1}meta,cn=config From : {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=people,dc=domain,dc=two,dc=com\")}$1$2" ":" To: {5}rewriteRule "^(.+uid=[^,]+)(a)domain.two.com(,.*)$" "${&&target(\"ou=mynetworkpeople,o=my.example.com\")}$1$2" ":" I get a segfault. Please find attached the gdb traces. Before segfault, slapd is able to log the following messages: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: 10rFeb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: read active on 10 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_get(10): got connid=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: connection_read(10): checking for input on id=1000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: op tag 0x66, time 1645812518 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 do_modify Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on 1 descriptor Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: activity on:Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=7 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: daemon: epoll: listen=8 active_threads=0 tvp=NULL Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config>, <olcMetaSub={0}uri,olcDatabase={1}meta,cn=config> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD dn="olcMetaSub={0}uri,olcDatabase={1}meta,cn=config" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: conn=1000 op=14 MOD attr=olcDbRewrite olcDbRewrite Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_get_csn: conn=1000 op=14 generated new csn=20220225180838.334352Z#000000#001#000000 manage=1 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: slap_queue_csn: queueing 0x7f030c140330 20220225180838.334352Z#000000#001#000000 Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_required entry (olcMetaSub={0}uri,olcDatabase={1}meta,cn=config), objectClass "olcMetaTargetConfig" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "objectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcMetaSub" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbURI" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbIDAssertBind" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRewrite" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbKeepalive" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbBindTimeout" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbCancel" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbChaseReferrals" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoRefs" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNoUndefFilter" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbNretries" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbProtocolVersion" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbRebindAsUser" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbSessionTrackingRequest" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "olcDbTFSupport" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "structuralObjectClass" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryUUID" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "creatorsName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "createTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "entryCSN" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifiersName" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: oc_check_allowed type "modifyTimestamp" Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: >>> dnPrettyNormal: <dc=my,dc=example,dc=com> Feb 25 19:08:38 mydevldapsrvmd21.datacenter.my.example.com slapd[1066842]: <<< dnPrettyNormal: <dc=my,dc=example,dc=com>, <dc=my,dc=example,dc=com> Best Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9818] New: slapo-translucent overlay crashes during wildcard search with subordinate
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9818 Issue ID: 9818 Summary: slapo-translucent overlay crashes during wildcard search with subordinate Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: jeremy.diaz(a)rexconsulting.net Target Milestone: --- I found that slapd 2.5.11 w/slapo-translucent will crash when queried with a wildcard search. It looks like any wildcard search on any attribute specified in "translucent_local" will cause the SIGSEGV on the latest version of Symas OpenLDAP slapd, 2.5.11, MDB databases, running on CentOS7. It seems that the SIGSEGV problem does not occur w the 2.4.44 from the RHEL7 distribution, and so the problem may have be a regression. I have not tested any other versions but have verified that, with the exact same config, the problem does not happen on the RHEL7 2.4.44 version, but does happen w/Symas OpenLDAP 2.5.11. It's an interesting config here. There are two database+suffixes defined in the instance. The first one is subordinate (ou=someorg,dc=corp,dc=com) to the second one (dc=corp,dc=com). The "subordinate" option is set to "True". The second database section loads the translucent overlay which is pointed to the upstream Active Directory instance and has the same suffix of AD. The problem is administrative. The group want their admins who manage LDAP data to be able to search using wildcard "cn=xyx*" filters. Besides crashing, we have noticed that these work, but only when setting the basedn of the subordinate database. I tried a few things in a test lab and was able to reproduce the issue. with "cn" in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry "(cn=je*)" filter crashes slapd with "cn" not in "translucent_local" and sublevel search of translucent superior basedn dc=corp,dc=com "(cn=jed)" filter return referrals from upstream Active Directory "(cn=je*)" filter return referrals from upstream Active Directory with "cn" in "translucent_local" and sublevel search of subordinate basedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg with "cn" not in "translucent_local" and sublevel search of subordinate dbasedn ou=someorg,dc=corp,dc=com "(cn=jed)" filter returns subordinate database entry from ou=someorg "(cn=je*)" filter returns subordinate database entry(ies) from ou=someorg Here's what the crash looks like: 622eb2f7.0393c4d6 0x7fcf15e89880 slapd starting 622eb2fd.32371976 0x7fce8d9f3700 slap_listener_activate(8): 622eb2fd.323bb364 0x7fce8d1f2700 >>> slap_listener(ldap:///) 622eb2fd.3247761c 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.3247962c 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.3247b177 0x7fce8d1f2700 ber_get_next 622eb2fd.3247e0b8 0x7fce8d1f2700 ber_get_next: tag 0x30 len 12 contents: 622eb2fd.3247f6f1 0x7fce8d1f2700 op tag 0x60, time 1647227645 622eb2fd.32480615 0x7fce8d1f2700 ber_get_next 622eb2fd.32484eca 0x7fce8d1f2700 conn=1000 op=0 do_bind 622eb2fd.324861e8 0x7fce8d1f2700 ber_scanf fmt ({imt) ber: 622eb2fd.324871c1 0x7fce8d1f2700 ber_scanf fmt (m}) ber: 622eb2fd.32488890 0x7fce8d1f2700 >>> dnPrettyNormal: <> 622eb2fd.32489324 0x7fce8d1f2700 <<< dnPrettyNormal: <>, <> 622eb2fd.3248ce51 0x7fce8d1f2700 do_bind: version=3 dn="" method=128 622eb2fd.3248efc7 0x7fce8d1f2700 send_ldap_result: conn=1000 op=0 p=3 622eb2fd.324906be 0x7fce8d1f2700 send_ldap_response: msgid=1 tag=97 err=0 622eb2fd.32492605 0x7fce8d1f2700 ber_flush2: 14 bytes to sd 15 622eb2fd.324ab763 0x7fce8d1f2700 do_bind: v3 anonymous bind 622eb2fd.325dc3b4 0x7fce8d1f2700 connection_get(15): got connid=1000 622eb2fd.325de12a 0x7fce8d1f2700 connection_read(15): checking for input on id=1000 622eb2fd.325dec44 0x7fce8d1f2700 ber_get_next 622eb2fd.325e0856 0x7fce8d1f2700 ber_get_next: tag 0x30 len 63 contents: 622eb2fd.325e1663 0x7fce8d1f2700 op tag 0x63, time 1647227645 622eb2fd.325e22e8 0x7fce8d1f2700 ber_get_next 622eb2fd.325e500c 0x7fce8d1f2700 conn=1000 op=1 do_search 622eb2fd.325e5ae0 0x7fce8d1f2700 ber_scanf fmt ({miiiib) ber: 622eb2fd.325e69ea 0x7fce8d1f2700 >>> dnPrettyNormal: <dc=corp,dc=com> 622eb2fd.325e98bd 0x7fce8d1f2700 <<< dnPrettyNormal: <dc=corp,dc=com>, <dc=corp,dc=com> 622eb2fd.325eaad7 0x7fce8d1f2700 ber_scanf fmt ({m) ber: 622eb2fd.325ebce5 0x7fce8d1f2700 ber_scanf fmt (m) ber: 622eb2fd.325eddcb 0x7fce8d1f2700 ber_scanf fmt ({M}}) ber: 622eb2fd.325f334c 0x7fce8d1f2700 ==> limits_get: conn=1000 op=1 self="[anonymous]" this="dc=corp,dc=com" 622eb2fd.325f4dcc 0x7fce8d1f2700 ==> translucent_search: <dc=corp,dc=com> (cn=jed*) Segmentation fault Thanks! -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9785] New: test050 deadlock
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9785 Issue ID: 9785 Summary: test050 deadlock Product: OpenLDAP Version: 2.5.11 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: --- Running test050 in a loop sometimes results in a deadlock. Took 17 iterations on one system, was 100% on another. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9789] New: syncprov uses a thread-local counters for the detached op
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9789 Issue ID: 9789 Summary: syncprov uses a thread-local counters for the detached op 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: --- Persistent searches routinely migrate across threads, however they keep using op->o_counters from the original search op which is meant to be thread-local. During shutdown, this counter can be destroyed as the original thread finishes, but the persistent search might still be live somewhere else. At that point, trying to acquire the destroyed sc_mutex fails and the thread usually stalls forever. slapd-asyncmeta is very likely to suffer from the same issues. A representative backtrace of this happening: Thread 3 (Thread 0x7f0b7d933640 (LWP 2928392) "slapd"): #0 futex_wait (private=0, expected=2, futex_word=0x7f0b74000ff8) at ../sysdeps/nptl/futex-internal.h:146 #3 0x00007f0b7fd17a05 in ldap_pvt_thread_mutex_lock (mutex=Locked by LWP 0) at thr_posix.c:313 #4 0x0000000000469564 in slap_send_search_entry (op=Search request conn=1003 op=1 = {...}, rs=Search entry = {...}) at result.c:1503 #5 0x00007f0b7f30561c in syncprov_sendresp (op=Search request conn=1003 op=1 = {...}, ri=0x7f0b701eb8e0, so=0x7f0b74102b20, mode=1) at syncprov.c:976 #6 0x00007f0b7f305064 in syncprov_qplay (op=Search request conn=1003 op=1 = {...}, so=0x7f0b74102b20) at syncprov.c:1028 #7 0x00007f0b7f304ecc in syncprov_qtask (ctx=0x7f0b7d932a58, arg=0x7f0b74102b20) at syncprov.c:1086 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9804] New: slapd.conf(5) - remove comment from syncrepl about sizelimit
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9804 Issue ID: 9804 Summary: slapd.conf(5) - remove comment from syncrepl about sizelimit Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- slapd.conf(5) and slapd-config(5) contain the following really mis-leading text: "The sizelimit and timelimit parameters define a consumer requested limitation on the number of entries that can be returned by the LDAP Content Synchronization operation; as such, it is intended to implement partial replication based on the size of the replicated database and on the time required by the synchronization." This is wrong. One cannot implement deterministic partial replication with these limits. => This text should be removed. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9808] New: olcLastBind populated incorrectly when converting from slapd.conf
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9808 Issue ID: 9808 Summary: olcLastBind populated incorrectly when converting from slapd.conf 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: --- Fix coming shortly. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9801] New: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know.
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9801 Issue ID: 9801 Summary: Segmentation Fault of Openldap 2.6.1 when the syncprov overlay tries to synchronize from ODSEE an attribute that it does not know. Product: OpenLDAP Version: 2.6.1 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: laurent.revillion(a)icloud.com Target Milestone: --- Created attachment 877 --> https://bugs.openldap.org/attachment.cgi?id=877&action=edit The files from gdb Hello, I just tested Opendlap 2.6.1 synchronization from ODSEE. It seemed to me that everything was going very well but I had a "Segmention Fault" when I tested on ODSEE to add the nsAccountLock: TRUE attribute. This attribute does not exist in the Openldap schema. The Openldap server detects the thing well but ... segmentation fault.:(( 620f6bd2.1b555d23 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b556639 0x7fd0c9aff700 ber_scanf fmt ({mM}) ber: 620f6bd2.1b5576f3 0x7fd0c9aff700 ldap_get_attribute_ber 620f6bd2.1b55b147 0x7fd0c9aff700 syncrepl_changelog_mods: rid=002 Invalid attribute nsAccountLock, attribute type undefined ./start-consumer1.sh : ligne 3 : 12531 Erreur de segmentation /opt/symas/lib/slapd -d 1 -u ldap -g ldap -h "ldap://:5389/" -f /opt/symas/config/static-test/slapd-dsee-consumer1.conf Attached are the files generated via gdb. Thanks Laurent -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9584] New: cn=config replication ops/refresh should pause server
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9584 Issue ID: 9584 Summary: cn=config replication ops/refresh should pause server Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Looking into this crash: https://git.openldap.org/openldap/openldap/-/jobs/7286 The thread in question is running a plain syncrepl refresh while another thread seems to have done the same. This thread fetched the entryUUID attribute of the 'cn=config' entry as 'a' and in the meantime, that entry has been rewritten, with 'a' presumably cleaned up and returned to the pool, so addressing a->a_nvals[0] is a NULL-dereference now. This might or might not be related to the fix in ITS#8102. -- You are receiving this mail because: You are on the CC list for the issue.

1 18

← Newer
1
...
6
7
8
9
10
11
12
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2022