openldap-bugs March 2021

openldap-bugs@openldap.org

1 participants
318 discussions

[Issue 9495] New: authz-regexp using dn: instead of a URI mangles characters with HTML excapes
by openldap-its＠openldap.org 25 Jun '21

25 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9495 Issue ID: 9495 Summary: authz-regexp using dn: instead of a URI mangles characters with HTML excapes Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Trying to use an authz-regexp that maps directly to dn-s by using "dn:..." instead of a URI results in the authz id having some characters "html escaped". As a result the authorized entity cannot be found. E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division" with olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com" fails. Debug logs show that the equal and the comma character return from ldap_bv2dn() in escaped forms, that are then substituted into the target dn and result in a dn that does not exist in the DIT. 6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara Jensen,ou=Informatio n Technology Division" 6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information Technolo gy Division [len=52] => ldap_dn2bv(16) <= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth)=0 6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth ... 6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" I suspect that when the "dn:..." form is used with authz-regexp the supplied authzid should _not_ have it's characters canonicalized because they will not be substituted into a URI. If so, this would be a bug. If not, there should be documentation on the restrictions on what characters can be used in authzid when the "dn:..." form is used. Tested against HEAD of master, although the version in the bug report is 2.5. See also Bug# 6912. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9444] New: Feature Request: Textual error data is not sent through chaining overlay
by openldap-its＠openldap.org 24 Jun '21

24 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9444 Issue ID: 9444 Summary: Feature Request: Textual error data is not sent through chaining overlay Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: andrewlanecarr(a)gmail.com Target Milestone: --- When operating in a replicated environment we would like to see the text message accompany the error code propagated to the other nodes in the cluster. For Example: Master Log - master slapd[406]: conn=1160 op=3 MOD attr=userPassword master slapd[406]: conn=1160 op=3 RESULT tag=103 err=19 text=Password is not being changed from existing value Slave Log - slave slapd[31094]: conn=1000 op=18 MOD attr=userPassword slave slapd[31094]: conn=1000 op=18 RESULT tag=103 err=19 text= The text "Password is not being changed from existing value" is not copied in this process. This is using the following configuration: -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Bug 9243] New: back-perl configure should test linking with libperl
by openldap-its＠openldap.org 23 Jun '21

23 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9243 Bug ID: 9243 Summary: back-perl configure should test linking with libperl Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- ./configure --enable-perl && make [...] checking for perl... /usr/bin/perl [...] libtool: link: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o txn.o slapschema.o slapmodify.o version.o -Wl,-E -fstack-protector-strong -pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.a /home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt -lresolv -pthread /usr/bin/ld: cannot find -lperl collect2: error: ld returned 1 exit status It should probably test compiling and linking a program with the detected CPPFLAGS and LDFLAGS. -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 9224] New: Add support for PREPARE/2-phase commit
by openldap-its＠openldap.org 23 Jun '21

23 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9224 Bug ID: 9224 Summary: Add support for PREPARE/2-phase commit Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In LMDB, add support for PREPARE/2-phase commits -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Issue 9363] New: removing olcReadOnly on a DB does not set it to FALSE
by openldap-its＠openldap.org 22 Jun '21

22 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9363 Issue ID: 9363 Summary: removing olcReadOnly on a DB does not set it to FALSE Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: maxime.besson(a)worteks.com Target Milestone: --- Created attachment 771 --> https://bugs.openldap.org/attachment.cgi?id=771&action=edit ldif config that reproduces the issue I am running the following test: * add olcReadOnly: TRUE on a MDB database in cn=config * Try to write to the MDB database => fails with "unwilling to perform" as expected * remove the olcReadOnly attribute from the MDB database * Try to write to the MDB database => still fails with the same error * Restart slapd * Try to write to the MDB database => OK However the following test works as expected: * add olcReadOnly: TRUE on a MDB database in cn=config * Try to write to the MDB database => fails with "unwilling to perform" as expected * modify olcReadOnly to FALSE on the MDB database * Try to write to the MDB database => OK It seems a little counter intuitive to me that removing a setting does not reset it to its default value. The fact that a slapd restart make writing possible again in the first test described above makes it seem to the casual user that olcReadOnly cannot be undone without a restart at all. Tested in 2.4.53 and 2.4.44, config attached but it probably works with any config (hdb, etc) -- You are receiving this mail because: You are on the CC list for the issue.

2 9

[Issue 9512] New: Add ability to restrict by client ip address in ACLs
by openldap-its＠openldap.org 14 Jun '21

14 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9512 Issue ID: 9512 Summary: Add ability to restrict by client ip address in ACLs Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently it is possible via ACLs to enforce restrictions based on which slapd host interface is connected to via the peername parameter. However, it's not possible to enforce ACL restrictions based on the IP address used by the client. This would be a useful feature when wanting to restrict certain DNs to only being able to have access if they connect from a certain IP or IP range. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9295 Issue ID: 9295 Summary: ppolicy and replication: pwdLockedTime replication fails to replicate Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If you have the following setup, a replica will hit an error during replication. a) ppolicy is configured on provider(s) and replicas. Replica has schemachecking=on in its syncrepl configuration b) account gets locked on the replica, so pwdAccountLockedTime is set on the replica but not on the provider(s) c) admin does a MOD/ADD op against a provider for the user entry to add a value to pwdAccountLockedTime dn: ... changetype: modify add: pwdAccountLockedTime pwdAccountLockedTime: ... d) provider accepts this modification. e) replica rejects this modification because the resulting change means that there would be two pwdAccountLockedTime values on the account in question Generally I believe that in this scenario, the MOD/ADD on the provider should be treated as a replace OP instead of an ADD op -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9494] New: Segfault after modify olcDbMaxSize w/ autogroup
by openldap-its＠openldap.org 04 Jun '21

04 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9494 Issue ID: 9494 Summary: Segfault after modify olcDbMaxSize w/ autogroup Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: louis.chanouha(a)univ-toulouse.fr Target Milestone: --- Hello, Yet another crash when modifying olcDbMaxSize. Seems not to be related to other similar reports. autogroup works fine until : - attempt to modify olcDbMaxSize - attempt to modify olcAGattrSet (segfault to, need to delete the overlay and add it again) - do not rely on olcMemberOfMemberAD (extra memberof module) requested change --------------------------------------------: dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcDbMaxSize olcDbMaxSize: 4294967296 openldap logs -----------------------------------------------: 6046b5c3 ==> autogroup_db_close 6046b5c3 ==> autogroup_db_close 6046b5c3 mdb_db_open: database "dc=domain,dc=fr": dbenv_open(/var/lib/ldap). 6046b5c3 ==> autogroup_db_open 6046b5c3 ==> autogroup_build_def_filter put_filter: "(objectClass=groupOfURLs)" put_filter: simple put_simple_filter: "objectClass=groupOfURLs" ber_scanf fmt ({mm}) ber: 6046b5c3 => mdb_search 6046b5c3 mdb_dn2entry("dc=domain,dc=fr") 6046b5c3 => mdb_dn2id("dc=domain,dc=fr") 6046b5c3 <= mdb_dn2id: got id=0x1 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 search_candidates: base="dc=domain,dc=fr" (0x00000001) scope=2 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read: failed (-30798) 6046b5c3 <= mdb_equality_candidates: id=0, first=0, last=0 6046b5c3 => mdb_equality_candidates (objectClass) 6046b5c3 => key_read 6046b5c3 <= mdb_index_read 5 candidates 6046b5c3 <= mdb_equality_candidates: id=5, first=18173, last=18177 6046b5c3 mdb_search_candidates: id=5 first=18173 last=18177 6046b5c3 => mdb_entry_decode: 6046b5c3 <= mdb_entry_decode 6046b5c3 ==> autogroup_group_add_cb <cn=cxxx,ou=groups,dc=domain,dc=fr> 6046b5c3 ==> autogroup_add_group <cn=xxx,ou=groups,dc=domain,dc=fr> Thread 3 "slapd" received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7feb7d42c700 (LWP 37453)] GDB dump -------------------------------------- (gdb) info frame Stack level 0, frame at 0x7feb7d297fd0: rip = 0x55b4569bcba0 in dnMatch; saved rip = 0x7feb9e5f768b called by frame at 0x7feb7d298070 Arglist at 0x7feb7d297f88, args: Locals at 0x7feb7d297f88, Previous frame's sp is 0x7feb7d297fd0 Saved registers: rbx at 0x7feb7d297f98, rbp at 0x7feb7d297fa0, r12 at 0x7feb7d297fa8, r13 at 0x7feb7d297fb0, r14 at 0x7feb7d297fb8, r15 at 0x7feb7d297fc0, rip at 0x7feb7d297fc8 (gdb) bt #0 0x000055b4569bcba0 in dnMatch () #1 0x00007feb9e5f768b in ?? () from /usr/lib/ldap/autogroup.so.0 #2 0x00007feb9e5f98fb in ?? () from /usr/lib/ldap/autogroup.so.0 #3 0x000055b4569b6eb8 in ?? () #4 0x000055b4569b8a31 in slap_send_search_entry () #5 0x00007feb9e63dbf6 in mdb_search () from /usr/lib/ldap/back_mdb-2.4.so.2 #6 0x000055b456a16c68 in overlay_op_walk () #7 0x000055b456a16d97 in ?? () #8 0x00007feb9e5f9be0 in ?? () from /usr/lib/ldap/autogroup.so.0 #9 0x000055b456a15dd8 in ?? () #10 0x00007feb9e632eb8 in ?? () from /usr/lib/ldap/back_mdb-2.4.so.2 #11 0x000055b4569908b6 in ?? () #12 0x000055b4569be8aa in fe_op_modify () #13 0x000055b4569c0930 in do_modify () #14 0x000055b4569a66ed in ?? () #15 0x000055b4569a722c in ?? () #16 0x00007feb9fa5ea03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 #17 0x00007feb9f990609 in start_thread (arg=<optimized out>) at pthread_create.c:477 #18 0x00007feb9f8b7293 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 cn=config overlays ---------------------------------- 22 olcOverlay={0}memberof,olcDatabase={1}mdb,cn=config objectClass: olcConfig objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf 23 olcOverlay={1}ppolicy,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcPPolicyConfig olcOverlay: {1}ppolicy olcPPolicyDefault: cn=orga_default,ou=Policies,dc=domain,dc=fr olcPPolicyHashCleartext: FALSE olcPPolicyUseLockout: TRUE olcPPolicyForwardUpdates: TRUE 24 olcOverlay={2}syncprov,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {2}syncprov 25 olcOverlay={3}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {3}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member 26 olcOverlay={4}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {4}autogroup olcAGattrSet: {0}groupOfURLs memberURL member olcAGmemberOfAd: memberOf 27 olcOverlay={5}memberof,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf objectClass: olcConfig olcOverlay: {5}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfURLs olcMemberOfMemberAD: member 28 olcOverlay={6}autogroup,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcAutomaticGroups olcOverlay: {6}autogroup olcAGattrSet: {0}groupOfURLs memberUidURL memberUid -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9487] New: Committed changes not saved to accesslog during shutdown
by openldap-its＠openldap.org 17 May '21

17 May '21

https://bugs.openldap.org/show_bug.cgi?id=9487 Issue ID: 9487 Summary: Committed changes not saved to accesslog during shutdown Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If there is inbound write traffic when slapd is asked to shut down, some of these operations get written to the main database but accesslog might be prevented from ADDing the log entry into its own database (presumably since slapd is shutting down already). This prevents these updates from being replicated in a deltasync scenario and silently desync. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9511] New: make depend shouldn't error on slapi/plugin.c if no ltdl.h found
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9511 Issue ID: 9511 Summary: make depend shouldn't error on slapi/plugin.c if no ltdl.h found Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- make depend throws the following error if ltdl.h is not found: make[3]: Entering directory '/home/quanah/qtest/openldap/qbuild/servers/slapd/slapi' ../../../../build/mkdep -l -d "../../../../servers/slapd/slapi" -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../../include -I../../../../servers/slapd/slapi/.. -I../../../../servers/slapd/slapi plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c ../../../../servers/slapd/slapi/plugin.c:33:10: fatal error: ltdl.h: No such file or directory #include <ltdl.h> ^~~~~~~~ I.e., it should probably just exit if HAVE_LTDL_H is not true or similar. At the least: diff --git a/servers/slapd/slapi/plugin.c b/servers/slapd/slapi/plugin.c index 7ebc23f3a..f816ea34e 100644 --- a/servers/slapd/slapi/plugin.c +++ b/servers/slapd/slapi/plugin.c @@ -30,7 +30,9 @@ /* * Note: if ltdl.h is not available, slapi should not be compiled */ +#ifdef HAVE_LTDL_H #include <ltdl.h> +#endif gets rid of the error during make depend -- You are receiving this mail because: You are on the CC list for the issue.

1 6

← Newer
1
...
4
5
6
7
8
9
10
...
32
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs March 2021