- openldap-bugs - openldap.org

[Issue 9045] Crashes in cn=config (test050)
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9045 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|VERIFIED |CONFIRMED Ever confirmed|0 |1 Resolution|WORKSFORME |--- --- Comment #3 from Ondřej Kuzník <ondra(a)mistotebe.net> --- Got another one, in do_syncrep1, attached. I gather it's because syncrepl got it through entry_get() while there is a modify request on cn=config that freed it in the meantime. Sounds like ldap_pvt_thread_rdwr_rlock( &cfb->cb_rwlock ) in config_back_entry_get (and the reverse in config_entry_release()) might do the trick, except that anyone getting that entry needs to release it before they yield processing - as bconfig might decide it wants to pause and wlock. Or we just entry_dup it unconditionally which means we never interfere with anyone else. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9939] New: datamorph test fails
by openldap-its＠openldap.org 24 Oct '22

24 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9939 Issue ID: 9939 Summary: datamorph test fails Product: OpenLDAP Version: 2.6.3 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: test suite Assignee: bugs(a)openldap.org Reporter: patrick+openldap.org(a)laimbock.com Target Milestone: --- [snip] + for MOD in datamorph ppm variant + pushd contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph ~/build/BUILD/openldap-2.6.3 + /usr/bin/make -O -j1 V=1 VERBOSE=1 test ln -s /builddir/build/BUILD/openldap-2.6.3/clients clients ln -s /builddir/build/BUILD/openldap-2.6.3/servers servers ln -s /builddir/build/BUILD/openldap-2.6.3/tests/progs tests/progs cd tests; \ SRCDIR=/builddir/build/BUILD/openldap-2.6.3 \ LDAP_BUILD=/builddir/build/BUILD/openldap-2.6.3 \ TOPDIR=/builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph \ LIBTOOL=/builddir/build/BUILD/openldap-2.6.3/libtool \ /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/run all Running /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/all for mdb... >>>>> Executing all LDAP tests for mdb >>>>> Starting test001-config for mdb... running defines.sh /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 26: /servers/slapd/slapd: No such file or directory /builddir/build/BUILD/openldap-2.6.3/contrib/slapd-modules/datamorph/tests/scripts/common.sh: line 28: /servers/slapd/slapd: No such file or directory Starting slapd on TCP/IP port 9011 for configuration... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Waiting 7 seconds for slapd to start... Failed testing for module load entry >>>>> test001-config failed for mdb (exit 127) make: *** [tests/Rules.mk:12: test] Error 127 This test also fails on the latest 2.6 branch. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8610] ldaps not usable with DNS SRV
by openldap-its＠openldap.org 21 Oct '22

21 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=8610 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The FAQ is historic, 99% of what's in it is incorrect. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9933] New: pamcompany
by openldap-its＠openldap.org 18 Oct '22

18 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9933 Issue ID: 9933 Summary: pamcompany Product: JLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: JDBC Assignee: bugs(a)openldap.org Reporter: packersnmoversservices(a)gmail.com Target Milestone: --- A trustworthy and expert moving business in Bangalore's Hebbal is PAM Bangalore. This business is regarded as one of the top packers and movers hebbal service providers because of its reputation for offering high-quality moving and shifting services at reasonable pricing. Relocators who require storage or house transferring services in Bangalore seek them. A firm with a team of professional packers and movers offers a hassle-free, damage-free, and stress-free move at a reasonable cost. https://www.packersmoversinbangalore.co.in/packers-and-movers-in-hebbal/ -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9927] New: mdb/0.9 update makes strange problems
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9927 Issue ID: 9927 Summary: mdb/0.9 update makes strange problems 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: dpa-openldap(a)aegee.org Target Milestone: --- Created attachment 919 --> https://bugs.openldap.org/attachment.cgi?id=919&action=edit strace outfput of failed start I changed on the 2.6 branch at this commit 18f6cc1609fe80ae30702f68875a6fc793e29ffd (origin/OPENLDAP_REL_ENG_2_6, OPENLDAP_REL_ENG_2_6) Merge: 8b4c915a6 d87d682b6 Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Tue Oct 4 14:29:39 2022 +0000 Merge remote-tracking branch 'origin/mdb.RE/0.9' into OPENLDAP_REL_ENG_2_6 and things stopped working: after several times restarting slapd refused to start. Then I went back to commit: commit 8b4c915a655373973a834719f942bcdc09a7b516 (HEAD) Author: Quanah Gibson-Mount <quanah(a)openldap.org> Date: Mon Oct 3 20:26:19 2022 +0000 ITS#9915 and things worked again. I changed back to commit 18f6cc1609fe8, and slapd does run properly. Of course, I assume the LMDB database format has not changed and I have not done export to LDIF and then import from LDIF to LMDB. I have disabled syslog and debugging: $ ./configure --disable-ipv6 --enable-spasswd --disable-static --disable-syslog --disable-debug --enable-sssvlv --disable-relay The file FAILED.txt, produced on dysfunctional slapd by executing # strace /usr/local/libexec/slapd -d0 -u openldap -r /home/openldap -F /etc/openldap/ -h'ldap://ldap.aegee.org/ ldaps://ldap.aegee.org ldapi://%%2Fvar%%2Frun%%2Fldapi' > FAILED.txt is attached. This is very similar to https://bugs.openldap.org/show_bug.cgi?id=9879 : upgrading to the newest version fails. Using a slightly older version than the tip of the tree does not fail any more. Then upgrading to the newest version does work. Note that yesterday, or two-three days ago I also upgraded to the newest tip of git and things worked, but I cannot say which commit was this. # journalctl --unit openldap Oct 04 08:04:31 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:04:33 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:04:33 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:04:33 mail systemd[1]: openldap.service: Consumed 50.080s CPU time. Oct 04 08:04:33 mail systemd[1]: Starting OpenLDAP... Oct 04 08:04:36 mail systemd[1]: Started OpenLDAP. Oct 04 08:10:33 mail systemd[1]: Stopping OpenLDAP... Oct 04 08:10:34 mail systemd[1]: openldap.service: Deactivated successfully. Oct 04 08:10:34 mail systemd[1]: Stopped OpenLDAP. Oct 04 08:10:37 mail systemd[1]: Starting OpenLDAP... Oct 04 08:10:37 mail systemd[1]: Started OpenLDAP. Oct 05 07:33:36 mail systemd[1]: Stopping OpenLDAP... Oct 05 07:33:37 mail systemd[1]: openldap.service: Failed with result 'resources'. Oct 05 07:33:37 mail systemd[1]: Stopped OpenLDAP. Oct 05 07:33:37 mail systemd[1]: openldap.service: Consumed 7.453s CPU time. Oct 05 07:33:37 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:38 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:38 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:38 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:33:43 mail systemd[1]: Starting OpenLDAP... Oct 05 07:33:43 mail systemd[1]: openldap.service: Main process exited, code=exited, status=255/EXCEPTION Oct 05 07:33:43 mail systemd[1]: openldap.service: Failed with result 'exit-code'. Oct 05 07:33:43 mail systemd[1]: Failed to start OpenLDAP. Oct 05 07:38:22 mail systemd[1]: Starting OpenLDAP... so it worked likely without problems on the most current 2.6 commit at Oct 04 08:04:33 UTC. Note that the failing slapd does terminate before reading the configuration files with newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 newfstatat(AT_FDCWD, "/etc/openldap/", {st_mode=S_IFDIR|0755, st_size=4096, ...}, 0) = 0 mmap(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f03c36d1000 openat(AT_FDCWD, "/etc/openldap//cn=config.ldif", O_RDONLY) = 9 newfstatat(9, "", {st_mode=S_IFREG|0600, st_size=817, ...}, AT_EMPTY_PATH) = 0 so it shall be irrelevant how MDB handles the data. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9932] New: Sync failing between two LDAP servers
by openldap-its＠openldap.org 13 Oct '22

13 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9932 Issue ID: 9932 Summary: Sync failing between two LDAP servers Product: OpenLDAP Version: 2.4.58 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shikhar81(a)gmail.com Target Milestone: --- Hi Team, We have noticed a sync issue in our environment. We have two production servers namely A and B and two DR servers namely C and D. A and B are in bi-directional sync A and C are in bi-directional sync B and D are in bi-directional sync Since the last few days the sync between A and C and B and D has broken and we are unable to see any concrete error in logs Just to add here that server A and server B are in the same subnet and server C & server D are in a different subnet. However, this setup has been working fine since the last many years with no issues at all. Since the last few days the connection has broken as mentioned earlier. Now we also tried to initiate a sync between C and D (DR servers) which are in the same subnet. But still it is not syncing and we get a "no connection" error message in the logs after trying for 2-3 hrs. Can you please suggest what can be done here. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9928] New: ldap_search_ext_s always hangs on 2.6.3
by openldap-its＠openldap.org 12 Oct '22

12 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9928 Issue ID: 9928 Summary: ldap_search_ext_s always hangs on 2.6.3 Product: OpenLDAP Version: 2.6.3 Hardware: All OS: Mac OS Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: filipe.custodio(a)gmail.com Target Milestone: --- Created attachment 920 --> https://bugs.openldap.org/attachment.cgi?id=920&action=edit Minimal AD query that consistently hangs on ldap_search_ext_s call Dear Experts, When using ldap_search_ext_s() from libldap v2.6.3 to do a simple search on our production Windows Domain Controller, the client consistently hangs forever. Using ldap_search_ext() & ldap_result() also hangs after delivering the first information item. It seems the client is left waiting, not realising no more results are coming from the server. Using the development image from Oct. 9 2022, the ldap_search_ext_s() call works, although it gives an "Operations Error". Shall I deploy the new libldap from the development branch in our production environment to solve this problem or is there another way around the issue? Best regards, Filipe Custódio -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9919] New: The use of a separate section for cold code can cause linking issues on macOS
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9919 Issue ID: 9919 Summary: The use of a separate section for cold code can cause linking issues on macOS Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- See e.g. https://github.com/llvm/llvm-project/issues/52767 -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its＠openldap.org 03 Oct '22

03 Oct '22

https://bugs.openldap.org/show_bug.cgi?id=9365 Issue ID: 9365 Summary: Mem leaks with Æ-DIR providers Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Created attachment 772 --> https://bugs.openldap.org/attachment.cgi?id=772&action=edit valgrind output on openSUSE Tumbleweed x86_64 An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now buster) has memory leak issues on the Æ-DIR providers. The read-only consumers do not have this issue. The provider config is more complex with more overlays and more ACLs. In this production deployment slapd is automatically restarted (by monit) when memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw tooth pattern. I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running slapd under control of valgrind for a couple of minutes continously sending simple bind operations (additional to the monitoring and other back-ground jobs running). Find valgrind output of my first attempt attached. Does that make sense at all? -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9923] New: extensible match ignored
by openldap-its＠openldap.org 28 Sep '22

28 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9923 Issue ID: 9923 Summary: extensible match ignored 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: francois(a)rcdevs.com Target Milestone: --- Hi, I'm trying to use a matching rule with slapd as a proxy in front of Active Directory with back-ldap The request is something similar to '(memberOf:1.2.840.113556.1.4.1941:=cn=gp1,o=Root)' It works if I use it directly on AD. Unfortunately, the request is ignored by slapd and not forwarded, I receive a "success" but the result is empty. The request is forwarded if I use something like this: '(memberOf=cn=gp1,o=Root)' Could it be possible to forward the request to the backend? slapd doesn't need to understand the meaning of the OID. slapd with matching rule: [2022-09-28 11:07:39] begin get_filter [2022-09-28 11:07:39] EXTENSIBLE [2022-09-28 11:07:39] daemon: activity on 1 descriptor [2022-09-28 11:07:39] end get_filter 0 [2022-09-28 11:07:39] filter: (?=undefined) [2022-09-28 11:07:39] attrs: dn [2022-09-28 11:07:39] conn=1000 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?=undefined)" slapd without matching rule: [2022-09-28 11:07:47] begin get_filter [2022-09-28 11:07:47] EQUALITY [2022-09-28 11:07:47] get_ava: unknown attributeType memberOf [2022-09-28 11:07:47] [2022-09-28 11:07:47] end get_filter 0 [2022-09-28 11:07:47] daemon: epoll: listen=7 active_threads=0 tvp=NULL [2022-09-28 11:07:47] daemon: epoll: listen=8 active_threads=0 tvp=NULL [2022-09-28 11:07:47] filter: (?memberOf=cn=gp1,o=Root) [2022-09-28 11:07:47] attrs: dn [2022-09-28 11:07:47] conn=1001 op=1 SRCH base="o=root" scope=2 deref=0 filter="(?memberOf=cn=gp1,o=Root)" searchrequest dump: 0000 30 56 02 01 02 63 51 04 06 6f 3d 72 6f 6f 74 0a 0V...cQ..o=root. 0010 01 02 0a 01 00 02 01 00 02 01 00 01 01 00 a9 32 ...............2 0020 81 17 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 ..1.2.840.113556 0030 2e 31 2e 34 2e 31 39 34 31 82 08 6d 65 6d 62 65 .1.4.1941..membe 0040 72 4f 66 83 0d 63 6e 3d 67 70 31 2c 6f 3d 52 6f rOf..cn=gp1,o=Ro 0050 6f 74 30 04 04 02 64 6e ot0...dn -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9878] New: test043 failures in 2.5/2.6
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9878 Issue ID: 9878 Summary: test043 failures in 2.5/2.6 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: --- With test043 update for ITS#9823, we manage to introduce a scenario where the server is completely idle except for a runqueue change. This is partly identical with ITS#9642 and a similar approach would work. Except that changes our module facing ABI so might not be something we can backport. For the streams we can't, we might have to change the test to make the server not idle. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9922] New: Uninitialized value reading in clients/tools/common.c:tool_bind()
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9922 Issue ID: 9922 Summary: Uninitialized value reading in clients/tools/common.c:tool_bind() Product: OpenLDAP Version: 2.6.3 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- One possible flow in https://git.openldap.org/openldap/openldap/-/blob/master/clients/tools/comm… is: int err; if ( result ) { rc = ldap_parse_result( ld, result, &err, &matched, &info, &refs, &ctrls, 1 ); if ( rc != LDAP_SUCCESS ) { tool_perror( "ldap_bind parse result", rc, NULL, matched, info, refs ); tool_exit( ld, LDAP_LOCAL_ERROR ); } } if ( err != LDAP_SUCCESS … When result is NULL, err is not initialized, and the last line reads uninitialized value. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 26 Sep '22

26 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|--- |0.9.30 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE0.9: • 4bb20ed0 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9030] Use sys/cachectl.h rather than asm/cachectl.h on mips
by openldap-its＠openldap.org 22 Sep '22

22 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9030 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Howard Chu <hyc(a)openldap.org> --- patched in mdb.master ; mdb.master3 ; mdb.RE/0.9 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9918] New: Can't log on git.openldap.org
by openldap-its＠openldap.org 22 Sep '22

22 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9918 Issue ID: 9918 Summary: Can't log on git.openldap.org Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: mh-bcrayqnc(a)glandium.org Target Milestone: --- Followup for https://github.com/LMDB/lmdb/pull/23#issuecomment-1254532527. I created the account in February, apparently, with login glandium, but I'm not sure what email. Presumably the one from this bugzilla account. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9524] New: Removing last entry in database triggers MDB_PROBLEM
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9524 Issue ID: 9524 Summary: Removing last entry in database triggers MDB_PROBLEM Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: kriszyp(a)gmail.com Target Milestone: --- With a fresh database, if you have have an open read transaction, and you create a new entry in a write transaction and commit it, and then create a new transaction and delete that entry, when you commit, it will return an MDB_PROBLEM from approximately line 4408 from the mt_loose_count/dirty_list check. This seems to occur on mdb.master3, but not mdb.master. Here is a minimal example/test-case of how to reproduce: MDB_env* env; mdb_env_create(&env); int rc, flags = 0; mdb_env_open(env, "test", flags, 0664); MDB_txn* readonly_txn; mdb_txn_begin(env, nullptr, MDB_RDONLY, &readonly_txn); MDB_txn* txn; MDB_dbi dbi; mdb_txn_begin(env, nullptr, 0, &txn); mdb_dbi_open(txn, nullptr, MDB_CREATE, &dbi); MDB_val val; val.mv_data = (void*) "test"; val.mv_size = 4; mdb_put(txn, dbi, &val, &val, 0); mdb_txn_commit(txn); mdb_txn_begin(env, nullptr, 0, &txn); mdb_del(txn, dbi, &val, nullptr); rc = mdb_txn_commit(txn); // this returns MDB_PROBLEM (let me know if this should be submitted differently) -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9910] New: undefined MDB_FDATASYNC in mdb.master3 on macOs
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9910 Issue ID: 9910 Summary: undefined MDB_FDATASYNC in mdb.master3 on macOs Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- Created attachment 912 --> https://bugs.openldap.org/attachment.cgi?id=912&action=edit patch I am using the mdb.master3 branch which contains the encryption codebase. While testing on macOS, compilation fails with "undefined MDB_FDATASYNC" This is because commit #d85fe32 https://git.openldap.org/openldap/openldap/-/commit/d85fe32dab55b88cec25fc7… introduced a bug in the sense that the #elif on line 167 is not executed if the previous #elif is true. So when defined(__APPLE__) && !defined(MDB_USE_ROBUST) is true, the following #elif is skipped. But this seconf @elif is essential, as it defines MDB_FDATASYNC Proposed patch: --- libraries/liblmdb/mdb.c | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index 5bdec70..b54c8ae 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -164,9 +164,10 @@ typedef SSIZE_T ssize_t; #if defined(__FreeBSD__) && defined(__FreeBSD_version) && __FreeBSD_version >= 1100110 # define MDB_USE_POSIX_MUTEX 1 # define MDB_USE_ROBUST 1 -#elif defined(__APPLE__) && !defined(MDB_USE_ROBUST) -# define MDB_USE_POSIX_SEM 1 #elif defined(__APPLE__) || defined (BSD) || defined(__FreeBSD_kernel__) +# if defined(__APPLE__) && !defined(MDB_USE_ROBUST) +# define MDB_USE_POSIX_SEM 1 +# endif # if !(defined(MDB_USE_POSIX_MUTEX) || defined(MDB_USE_POSIX_SEM)) # define MDB_USE_SYSV_SEM 1 # endif -- -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9911] New: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose
by openldap-its＠openldap.org 21 Sep '22

21 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9911 Issue ID: 9911 Summary: MDB_PROBLEM: Unexpected problem - txn should abort, because of mdb_page_loose Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: info(a)parlepeuple.fr Target Milestone: --- In mdb.master3, when running some test suite, the transaction commit fails with MDB_PROBLEM: Unexpected problem - txn should abort The operation that where executed on a blank database: mdb_env_create mdb_env_open with CREATE mode mdb_txn_begin RW mdb_put one key value mdb_txn_commit mdb_txn_begin RW mdb_drop mdb_txn_commit This last commit fails with : MDB_PROBLEM: Unexpected problem - txn should abort My investigation shows that the lines 4401-4403 are triggered: if ((unsigned)txn->mt_loose_count != txn->mt_u.dirty_list[0].mid) { rc = MDB_PROBLEM; /* mt_loose_pgs does not match dirty_list */ goto fail; } And this is because of the commit #12ee1a2 "Use mdb_page_loose() more" https://git.openldap.org/openldap/openldap/-/commit/12ee1a2d7104616ccb812db… that does a mdb_page_loose instead of a mdb_midl_append on line 9496. Reverting this commit solves the problem. This commit seems to be a non essential optimization. But you will see into it as i am not so familiar with the refactoring that Hallvard Furuseth did back in July 2017. It would be nice to have an official fix from you, instead of this revert I did temporally to be able to continue working. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

Using self signed certificate causes ldap_sasl_bind_s() error
by rinchive＠gmail.com 20 Sep '22

20 Sep '22

Hi. I'm trying to use C code of your gitlab repository to make a program that can bind to remote LDAP server. I have some problems with using self signed certificate in openldap server. When I try to connect to remote LDAP server with SSL connection, ldap_sasl_bind_s return this error : "Can't contact LDAP server (-1) additional info: error:1416F086:SSL routines:tls_process_server_certificate:certificate verify failed (self signed certificate in certificate chain) " At the same time, server prints like this : 632973de conn=1018 fd=12 ACCEPT from IP=172.17.0.1:57250 (IP=0.0.0.0:636) TLS: can't accept: A TLS fatal alert has been received.. 632973de conn=1018 fd=12 closed (TLS negotiation failure) I use docker image to build an openldap server for test and made my own CA certificates, server's private key and certificate for TLS connection. On client program side, I set some options related to TLS connection. I set LDAP_OPT_X_TLS_REQUIRE_CERT to LDAP_OPT_X_TLS_NEVER, and set LDAP_OPT_X_TLS_CACERTDIR, LDAP_OPT_X_TLS_CACERTFILE to the path that server's CA certificate file is stored. I think I set all options that I can do on client side, but client always verify server's certificate and return "certificate verify failed (self signed certificate in certificate chain)" this error. It is okay to bind without TLS negotiation on client program. Also I made a connection with the server using LDAPAdmin which is windows ldap client program and it makes TLS connection successfully. Is there other option or some codes to be executed to make a secure connection using self signed certificate? I've been struggling with this error for a couple of weeks and not able to find a solution. Can I make a TLS connection with the server that uses the self-signed certificate?

1 0

[Issue 8912] incorrect rootDSE (namingContexts)
by openldap-its＠openldap.org 15 Sep '22

15 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #8 from Cliff <cwheat(a)sterlingandzoe.info> --- Thank you for the reply and my apologies for the lack of clarity. Upon further testing, I was unable to reproduce the behavior using a command line application, ldapsearch. I should have done that before submitting the bug. If you have been assigned this issue then please close it. I hope this is more clear: When attempting to display all of the subordinate partitions in the root partition I was only able to see a portion. Those displayed results were all of the same naming context, relative DN c=* or o=*. There is some form of filtering done by the LDAPBrowser GUI. This does not happen using ldapsearch. The problem is not in slapd as I initially thought. Thanks again for your reply. --Cliff On Monday, September 12, 2022 at 12:44:54 PM EDT, <openldap-its(a)openldap.org> wrote: https://bugs.openldap.org/show_bug.cgi?id=8912 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Cliff from comment #6) > On Fedora Core 36, > @(#) $OpenLDAP: slapd 2.6.2 (Aug 15 2022 00:00:00) $ > openldap > Included static backends: > config > ldif > monitor > mdb > using LDAP Browser\Editor v2.8.1: > > While attempting to add subordinate naming contexts off of base DN "" > (RootDSE), slapd will only show such subordinate naming contexts if they are > of the same RDN attribute. For instance, using all of FC36's trusted CA > certificates DN, which boil down to those based at c=?, or o=?, only those > of the same attribute will display as subordinates to "". I either get all > c= or o=, but not both. The subordinate naming context attribute that comes > in the configuration file determines which attribute will be shown. Hello, I honestly have no idea what you're trying to say here, but it seems thoroughly unrelated to this issue. If you feel that you've found an actual bug, then you should file something new with complete reproduction steps. If you're having issues understanding how to execute queries to OpenLDAP correctly please email the openldap-technical list. Regards, Quanah -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9339 Issue ID: 9339 Summary: Add syncrepl status in cn=monitor Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Patch coming to expose some consumer state in cn=monitor Sample entry: # Consumer 001, database 2, databases, monitor dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor objectClass: olmSyncReplInstance structuralObjectClass: olmSyncReplInstance cn: Consumer 001 creatorsName: modifiersName: createTimestamp: 20200906160447Z modifyTimestamp: 20200906160447Z olmSRProviderURIList: ldap://localhost:9011/ olmSRIsConnected: TRUE olmSRSyncPhase: Persist olmSRLastConnect: 20200906160448Z olmSRLastContact: 20200906160453Z olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000 000 olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000 000 entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor subschemaSubentry: cn=Subschema hasSubordinates: FALSE -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9853] New: lastbind-precision conversion fails from slapd.conf to cn=config
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9853 Issue ID: 9853 Summary: lastbind-precision conversion fails from slapd.conf to cn=config Product: OpenLDAP Version: 2.6.2 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: --- When converting a slapd.conf file to cn=config, the "lastbind-precision" value is not preserved. slapd.conf: lastbind-precision 300 cn=config value: olcLastBindPrecision: 0 -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9437 Issue ID: 9437 Summary: Add OTP module to core Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Symas will contribute its OTP module for OpenLDAP 2.5 as a core overlay -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6035] slapd requires restart after modifying olcAuthzRegexp
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=6035 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • f3ed13fa by Ondřej Kuzník at 2022-09-01T10:09:27+01:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE26: • d598f537 by Ondřej Kuzník at 2022-09-12T20:43:29+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak RE25: • 1b80eb42 by Ondřej Kuzník at 2022-09-12T20:43:41+00:00 ITS#6035 Plug olcAuthIDRewrite cn=config leak -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9817] New: rwm overlay : Issue with DN containing special characters
by openldap-its＠openldap.org 12 Sep '22

12 Sep '22

https://bugs.openldap.org/show_bug.cgi?id=9817 Issue ID: 9817 Summary: rwm overlay : Issue with DN containing special characters Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: thierry.pubellier(a)paris.fr Target Milestone: --- Hi, I'm using rwn to select the database useg for bind operations based on the result of a rewriteMap requets. Sample configuration in global section : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Everything goes fine until I use DN with special characters, like ',' or '['. For example : 'cn=Pubellier\, Thierry (TEST),ou=users,dc=paris,dc=local' In this case, the rwm-rewriteRule contructs a LDAP filter with incorrect syntax, as special caracters are not being escaped. I have to use some ugly tricks to escape these caracters, as shown below : #Rewrite Map to request a remote server rwm-rewriteMap ldap checkEntry "ldap://10.1.2.3/ou=users,dc=paris,dc=local?dn?sub" binddn="cn=myuser,ou=users,dc=paris,dc=local" credentials="XXX" # Backing up original DN rwm-rewriteRule ".+" "${&binddn($0)}$0" ":" # Rewriting for ',' rwm-rewriteRule "(.+).\2C(.+)" "$1\\,$2" # Adding a special '#' (asserting it in none of my DNs) suffix for special characters, in order to escape them without looping forever rwm-rewriteRule "(.*)([)*(\\])([^#].*|$)" "$1$2#$3" # Escaping of special characters with dedicated '#' suffix, avoiding infinite loops rwm-rewriteRule "(.*)([)*(\\])#(.*)" "$1\\$2$3" # Contructing LDAP Filter for remote search. Combined with a rewrite Map, the requested DN is returned if there is a match. rwm-rewriteRule ".+" "(&(!(description=TEST))(distinguishedName=$0))" ":" # If filter matches, end of rewriting. Going to 'dc=paris,dc=local' database rwm-rewriteRule ".+" "${checkIfPasswordExpiredDN($0)}" ":@I" # Otherwise, restoring the original DN. rwm-rewriteRule ".+" "${*binddn}" ":" # And final DN massaging from "dc=paris,dc=local" to "dc=paris,dc=local2" database rwm-rewriteRule "(.+,)?ou=users,dc=paris,dc=local$" "$1ou=users,dc=paris,dc=local2" ":@" Could there be a way to integrate the ldap escape mechanism when making an variable assignment (like using a '#' character in place of the usual '&') ? Thanks by advance, Best regards, Thierry -- You are receiving this mail because: You are on the CC list for the issue.

1 21

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs