- openldap-bugs - openldap.org

[Issue 9702] New: slapadd is missing -r chroot option
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9702 Issue ID: 9702 Summary: slapadd is missing -r chroot option Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I want to run slapd under chroot with the -r option. In order to initialize the setup, I want to use `slapadd -n0 configuration.ldif`. The configuration file contains mdb databases and these databases have `olcDbDirectory: ` paths. Since slapd will load the databases from the chroot environment, the directory names must be submitted to slapadd to be correct in the chroot environment. This means, that outside the chroot environment the directory paths are not correct. When I call `slapadd -n0 ` I get the error olcDbDirectory: value #0: invalid path: No such file or directory slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=909): Closing DB... which means, that slapadd cannot open (outside the chrooted environment) the olcDbDirectory path. Thus slapadd shall first enter the chrooted environment, but it lacks option for this. Probably slapcat will also need this option to dump the databases. The chrooted environment is created specially for openldap, so it contains no tools. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9845] New: slapd Deamon is Crashed on OpenVMS_x86
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9845 Issue ID: 9845 Summary: slapd Deamon is Crashed on OpenVMS_x86 Product: OpenLDAP Version: 2.5.7 Hardware: x86_64 OS: Other Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: jeetu.singh(a)aol.com Target Milestone: --- CH2105_SYSTEM> @SYS$COMMON:[SYS$STARTUP]LDAP$STARTUP.COM; %RUN-S-PROC_ID, identification of created process is 20E0043A CH2105_SYSTEM> sho time 11-MAY-2022 06:09:20 CH2105_SYSTEM> sho proc/id=20E0043A %SYSTEM-W-NONEXPR, nonexistent process CH2105_SYSTEM> ty ldap$varroot:[run]slapd.log; $ runcmd = "$ldap$bin:slapd.exe" $ dbglvl = f$trnlnm("LDAP$DEBUG") $ if dbglvl .nes. "" then runcmd = "$ldap$bin:slapd.exe -d " $ runcmd %DEBUGBOOT-W-EXPGFLQUOTA, exceeded pagefile quota %SYSTEM-W-EXIT_UNWIND, exit unwind currently in progress SYSTEM job terminated at 11-MAY-2022 06:09:17.86 Accounting information: Buffered I/O count: 778 Peak working set size: 44368 Direct I/O count: 117 Peak virtual size: 962112 Page faults: 3447 Mounted volumes: 0 Charged CPU time: 0 00:00:00.38 Elapsed time: 0 00:00:00.50 Please let me know if any further input needed. Request to provide "How to configure OpenLDAP on OpenVMS_x86 Environment" Manual. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9745] New: Local Logging - Timestamp Formatting
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9745 Issue ID: 9745 Summary: Local Logging - Timestamp Formatting Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- Timestamps for log lines in the 2.6+ local logging feature are saved unformatted (ex: "618ae741.0f6eb63a"). This has the potential to break any log aggregation/analysis program like splunk that expect timestamps in syslog format. These timestamps should configurable in various syslog formats. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9403] New: add option to completely disable syslog logging
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=9403 Issue ID: 9403 Summary: add option to completely disable syslog logging Product: OpenLDAP Version: 2.4.45 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: cvuillemez(a)yahoo.fr Target Milestone: --- For auditing purpose, I need to enable "stats" loglevel. So on heavy load, slapd send lots of events to local syslog socket /dev/log, when compiled with LDAP_SYSLOG (on Debian / Ubuntu). It worked fine on old systems with a simple syslog service. But when upgrading on system with journald+syslog, CPU "overhead" becomes totally crazy. It would be great to have an option at run time to completely disable syslog logging, or/and use a cutom socket, e.g. /run/systemd/journal/syslog to bypass journald service. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 12 May '22

12 May '22

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cvuillemez(a)yahoo.fr --- Comment #23 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9403 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 9844] New: Monitoring your SEO strategy is essential
by openldap-its＠openldap.org 09 May '22

09 May '22

https://bugs.openldap.org/show_bug.cgi?id=9844 Issue ID: 9844 Summary: Monitoring your SEO strategy is essential Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: guptaaaron29(a)gmail.com Target Milestone: --- Monitoring your SEO strategy is essential to measure the success of your website. Fortunately, with the tools available today, it is possible to count all the variables to formulate new tactics or improve existing plans. Whether you need to analyze traffic, potential customers, keyword rankings, among other indicators, by using metrics, you will be able to obtain all the important information you need to know the actual performance of your strategy and improve SEO ranking. https://ghareluupcharinhindi.com/diabetes-ke-lakshan/ -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9842] New: Page should not be spilled if MDB_RESERVE is used
by openldap-its＠openldap.org 06 May '22

06 May '22

https://bugs.openldap.org/show_bug.cgi?id=9842 Issue ID: 9842 Summary: Page should not be spilled if MDB_RESERVE is used Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: stephan.j.bircher(a)gmail.com Target Milestone: --- The documentation for the function mdb_cursor_put states for MDB_RESERVE the following: "return a pointer to the reserved space, which the caller can fill in later". However this seems only to be valid if no other operation is performed on the cursor. Once the cursor is moved the page where the reserved data resides on might become untracked and therefore eligible to be spilled at any time. This problems occurrs however only for large transactions where lmdb starts to spill and flush pages. I'm using only lmdb and I'm a bit confused as the branches master (https://git.openldap.org/openldap/openldap/-/tree/master/libraries/liblmdb) and mdb.master (https://git.openldap.org/openldap/openldap/-/tree/mdb.master/libraries/libl…) are not the same. For example the function mdb_pages_xkeep differs and master and mdb.master. Will the branches be consolidated again? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8882] Empty Directory String Overlay
by openldap-its＠openldap.org 06 May '22

06 May '22

https://bugs.openldap.org/show_bug.cgi?id=8882 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Null Attribute Value |Empty Directory String |Overlay |Overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 06 May '22

06 May '22

https://bugs.openldap.org/show_bug.cgi?id=8882 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |IN_PROGRESS Ever confirmed|0 |1 --- Comment #15 from Ondřej Kuzník <ondra(a)mistotebe.net> --- https://git.openldap.org/openldap/openldap/-/merge_requests/523 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8882] Null Attribute Value Overlay
by openldap-its＠openldap.org 05 May '22

05 May '22

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

1 0

[Issue 9830] New: slapd using more memory on linux kernel 5.xx then kernel 4.19
by openldap-its＠openldap.org 05 May '22

05 May '22

https://bugs.openldap.org/show_bug.cgi?id=9830 Issue ID: 9830 Summary: slapd using more memory on linux kernel 5.xx then kernel 4.19 Product: OpenLDAP Version: 2.4.59 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: pavel.mamonov(a)wildix.com Target Milestone: --- Hi, there After upgrade a debian distro from 10 to 11 we are faced with consumption of memory more then before. We testing on the same system with different kernels. ======================================== System with a kernel 4.19: using of memory (slapd) ~ 100-120mb (max) slapd 2.4.59 libc6:amd64 2.31-13+deb11u2 linux-image-4.19.0-14-cloud-amd64 4.19.171-2 ======================================== System with a kernel 5.10: using of memory (slapd) ~ 135-235mb (max) slapd 2.4.59 libc6:amd64 2.31-13+deb11u2 linux-image-5.10.0-10-cloud-amd64 5.10.84-1 ======================================== Also we tried to use other allocator of memory like "libtcmalloc-minimal4:amd64 2.8.1-1" - but, unfortunately, it does not help us. Could you give advice what we can do for optimize memory and reduction using of it ? If need additional info please, let me know. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9675] New: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9675 Issue ID: 9675 Summary: Allow overwriting the default SLAPD_DEFAULT_CONFIGDIR during ./configure Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 839 --> https://bugs.openldap.org/attachment.cgi?id=839&action=edit fix I want to have different default for SLAPD_DEFAULT_CONFIGDIR in my slapd. By calling CPPFLAGS="-DSLAPD_DEFAULT_CONFIGDIR='\"/new/config/dir/\"'" ./configure one can change the default configdir in slapd. Provided that the macro SLAPD_DEFAULT_CONFIGDIR is not changed in the code, which is ensured by the provided patch. Macro SLAPD_DEFAULT_UCDATA is not used anywhere. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=8255 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 9814] New: upgrade ppm to 2.1 release
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9814 Issue ID: 9814 Summary: upgrade ppm to 2.1 release 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: david.coutadeur(a)gmail.com Target Milestone: --- Hello, I have just opened two new MR to upgrade ppm to 2.1 release: * for OpenLDAP 2.5: https://git.openldap.org/openldap/openldap/-/merge_requests/509 * for OpenLDAP 2.6: https://git.openldap.org/openldap/openldap/-/merge_requests/510 Changes: - Reject password if it contains tokens from an attribute of the LDAP entry https://github.com/ltb-project/ppm/issues/17 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9737] New: ldapdelete unable to prune LDAP subentries
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9737 Issue ID: 9737 Summary: ldapdelete unable to prune LDAP subentries 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: neuroc0der(a)gmail.com Target Milestone: --- ldapdelete has a builtin capability to prune LDAP subentries (RFC 3672) by utilizing LDAP subentries control when tracking children however currently that logic does not work in the code and pruning always fails with 66 / 'not allowed on non-leaf'. the test case for this is a normal parent entry which has LDAP subentry type children underneath. the patch below addresses this issue. From ba29cbf20804d1c73cc0b5ab16549c4faba75a9e Mon Sep 17 00:00:00 2001 From: Anton Bobrov <antbob(a)users.noreply.github.com> Date: Thu, 4 Nov 2021 17:27:34 +0100 Subject: [PATCH] ldapdelete unable to prune LDAP subentries --- clients/tools/ldapdelete.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/clients/tools/ldapdelete.c b/clients/tools/ldapdelete.c index 8aa8e8c12..1a93aaadf 100644 --- a/clients/tools/ldapdelete.c +++ b/clients/tools/ldapdelete.c @@ -279,8 +279,13 @@ retry:; } rc = ldap_parse_result( ld, res, &code, &matcheddn, &text, &refs, &ctrls, 1 ); + if( rc != LDAP_SUCCESS ) { + fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n", + prog, ldap_err2string( rc ), rc ); + return rc; + } - switch ( rc ) { + switch ( code ) { case LDAP_SUCCESS: break; @@ -292,9 +297,7 @@ retry:; /* fallthru */ default: - fprintf( stderr, "%s: ldap_parse_result: %s (%d)\n", - prog, ldap_err2string( rc ), rc ); - return rc; + break; } if( code != LDAP_SUCCESS ) { -- 2.31.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9787] New: 2.6.1 segfault in slaptest when logfile-format param is set
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9787 Issue ID: 9787 Summary: 2.6.1 segfault in slaptest when logfile-format param is set Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Segfault in slaptest when any value for logfile-format is set. debug, syslog-utc, etc. This doesn’t occur during slapd startup. Only in slaptest. Observed on U20 and R8 platforms. slapd.conf ``` logfile "/var/symas/openldap-data/openldap26.log" logfile-only on # segfaults when any value for: logfile-format syslog-utc ``` Backtrace: ``` #0 0x00007f8fca27f685 in __strlen_avx2 () from /lib64/libc.so.6 #1 0x000055df6eaddedf in config_logging (c=<optimized out>) at logging.c:731 #2 0x000055df6ea9fe33 in config_set_vals (Conf=0x55df6edbe348 <config_back_cf_table+3432>, c=0x55df70bc4080) at config.c:378 #3 0x000055df6eaa3010 in read_config_file (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", depth=depth@entry=0, cf=cf@entry=0x0, cft=cft@entry=0x55df6edbd5e0 <config_back_cf_table>) at config.c:908 #4 0x000055df6ea98b98 in read_config (fname=fname@entry=0x7ffe8f3a4706 "/opt/symas/etc/openldap/slapd.conf", dir=dir@entry=0x0) at bconfig.c:4519 #5 0x000055df6eb29946 in slap_tool_init (progname=progname@entry=0x55df6eb50da3 "slaptest", tool=tool@entry=8, argc=4, argv=0x7ffe8f3a28f8) at slapcommon.c:682 #6 0x000055df6eb2c27e in slaptest (argc=<optimized out>, argv=<optimized out>) at slaptest.c:99 #7 0x000055df6ea8baea in main (argc=4, argv=0x7ffe8f3a28f8) at main.c:287 (gdb ``` -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9780] New: Documenting sticky session support in 2.6
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9780 Issue ID: 9780 Summary: Documenting sticky session support in 2.6 Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://www.openldap.org/doc/admin26/loadbalancer.html contains the documentation for lload version 2.6. It says: • 2.6 release of lloadd will include sticky sessions (coherency). Since this is the documentation for version 2.6, the documentation shall say what is included in v2.6, not what will be included in v2.6. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9790] New: Build failure with GCC 4.1 and 4.3
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9790 Issue ID: 9790 Summary: Build failure with GCC 4.1 and 4.3 Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- In file included from ../../include/lutil.h:21, from passwd.c:60: ../../include/ac/socket.h:247: error: redefinition of typedef 'Sockaddr' ../../include/ldap_pvt.h:188: error: previous declaration of 'Sockaddr' was here -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9788] New: make warns about disabling/resetting jobserver
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9788 Issue ID: 9788 Summary: make warns about disabling/resetting jobserver Product: OpenLDAP Version: 2.6.1 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: orgads(a)gmail.com Target Milestone: --- Running make -j8 issues the following warning for each directory with make 4.3: make[2]: warning: -j8 forced in submake: resetting jobserver mode. with make 4.2.1: make[3]: warning: -jN forced in submake: disabling jobserver mode. With make 3.82 there is no warning, but the jobserver flags are duplicated for each nested directory. e.g.: cd back-monitor && make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 -j all On my env this is fixed by removing all the occurrences of $(MFLAGS) from build/dir.mk. MFLAGS is picked up by make when it exists, and there is no need to pass it explicitly. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9831] New: connection_next() can skip an active connection
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9831 Issue ID: 9831 Summary: connection_next() can skip an active connection 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: --- Uncovered by running test056 under interesting conditions repeatedly. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9809] New: slapo-pcache: incorrect call to monitor unregister_entry
by openldap-its＠openldap.org 04 May '22

04 May '22

https://bugs.openldap.org/show_bug.cgi?id=9809 Issue ID: 9809 Summary: slapo-pcache: incorrect call to monitor unregister_entry Product: OpenLDAP Version: 2.4.18 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: --- Also an incorrect check for whether monitoring was initialized, thus calling unregister_entry_callback when there's nothing to unregister. The incorrect call causes a SEGV. The incorrect call is also present in back-mdb, but never invoked because it correctly sees there's nothing to unregister. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs