- openldap-bugs - openldap.org

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 07 Sep '21

07 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Need code to be shared between slapd and loadbalancer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9665] New: wrong indentation in ldap_int_bisect_find
by openldap-its＠openldap.org 07 Sep '21

07 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9665 Issue ID: 9665 Summary: wrong indentation in ldap_int_bisect_find Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: roland.illig(a)gmx.de Target Milestone: --- In abandon.c, ldap_int_bisect_find has an incorrectly indented if statement. I stumbled upon this due to a lint warning and immediately wondered who forgot to format the code again, probably after removing a redundant outer if statement or loop. The wrong indentation was introduced by https://git.openldap.org/openldap/openldap/-/commit/2660518c5d924b2b6377a87… in 2008. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9663] New: Compilation problems: Perl backend
by openldap-its＠openldap.org 06 Sep '21

06 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9663 Issue ID: 9663 Summary: Compilation problems: Perl backend Product: OpenLDAP Version: 2.5.6 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: jb00356987(a)techmahindra.com Target Milestone: --- Dears, I try to compile 2.5.6 version with --enable-perl module but I get issue as following : first I get : In file included from init.c:18: perl_back.h:21:10: fatal error: EXTERN.h: No such file or directory #include <EXTERN.h> ^~~~~~~~~~ compilation terminated. make[3]: *** [Makefile:334: init.lo] Error 1 I had to install a missing rehl package (perl-devel.x86_64) and set the CPPFLAGS of the "configure utility" to the path of these header files. I did run "make clean" and restart the full comilation process then "make" goes futher but now I get a lot of entries as below then it stopped : /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:50: undefined reference to `Perl_pop_scope' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:48: undefined reference to `Perl_sv_2iv_flags' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:50: undefined reference to `Perl_free_tmps' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:36: undefined reference to `Perl_stack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:34: undefined reference to `Perl_markstack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:35: undefined reference to `Perl_stack_grow' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:45: undefined reference to `Perl_croak_nocontext' /usr/app/LDAP/binaries/openldap-2.5.6/servers/slapd/back-perl/delete.c:28: undefined reference to `Perl_croak_nocontext' collect2: error: ld returned 1 exit status make[2]: *** [Makefile:527: slapd] Error 1 Any idea of what's the issue ? Configure used : ./configure --enable-modules --enable-ldap --enable-dynlist --enable-ppolicy --enable-unique --with-gnu-ld --enable-refint --with-tls --enable-dynamic --enable-valsort --enable-perl --enable-rwm Thx, Jean-Luc. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9662] New: Error while adding user/group in openldap
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9662 Issue ID: 9662 Summary: Error while adding user/group in openldap Product: OpenLDAP Version: 2.4.56 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: is3871(a)att.com Target Milestone: --- Created attachment 837 --> https://bugs.openldap.org/attachment.cgi?id=837&action=edit Error details Error while adding user/group in openldap adding new entry "dc=ajp,dc=att,dc=com" ldap_add: Server is unwilling to perform (53) additional info: no global superior knowledge -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|needs_review | Target Milestone|2.7.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8255] slapd-sock: response parsing in str2result() is broken
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8255 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.7.0 |2.6.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9651] New: Add some kind of rate limiting option to ldapmodify
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9651 Issue ID: 9651 Summary: Add some kind of rate limiting option to ldapmodify Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When using ldapmodify to replay a testing workload it would be useful to be able to specify a request rate, instead of just performing multiple operations in immediate succession. As a simpler alternative, just being able to specify a time interval between operations would be helpful. As an even greater future enhancement, it would be nice to have an option to replay an accesslog.ldif directly, using its embedded timestamps to control the time interval between operations. Currently this isn't feasible since reqstart timestamps only have 1-second granularity, the fraction part is a linear counter and not a microsecond value. The reqStart fraction would need to be extended to 9 decimal places with full nanosecond resolution in order to be usable as actual fractional time. We already know that microsecond resolution is insufficient to avoid frequent collisions. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9661] New: How to monitor an LDMB file for being pretty full
by openldap-its＠openldap.org 02 Sep '21

02 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9661 Issue ID: 9661 Summary: How to monitor an LDMB file for being pretty full Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://ltb-project.org/documentation/nagios-plugins/check_lmdb_usage provides a Nagios plugin, to check how full/free a LMDB database is. It calls mbd_stat -ef, and parses from the output the numbers in the “Max pages:”, “Number of pages used:”, and “Free pages:” lines. With these numbers it calculates “the percent of used pages” or “the percent of free pages” and signals the status with return values 0 -OK, 1 - warning, or 2 - critical . The disadvantage of check_lmdb_usage is, that it requires perl. Do you recommend to monitor the absolute number of free pages, the relative number of free pages, the absolute number of used pager, or the relative number of used pages? Please extend mdb_stat to be suitable for monitoring the fullness of a LMDB directory - accept parameters of for a warning and critical threshold, and a parameter on how to calculate the criterion (A - based on absolute number of free pages, B - relative number of free pages, C - absolute number of used pages, or D - relative number of used pages). -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #7 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- I can reproduce it on any sufficiently large db, both tree-structured or flat, given the right search scope. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |needs_review --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- I'll put needs review on it though so we can discuss. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to geert.hendrickx(a)telenetgroup.be from comment #4) > Hi > > I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly > slapadd'ed mdb. Target milestone for the fix is 2.7.0, so that's expected. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8375] paged results control results in full db search?
by openldap-its＠openldap.org 01 Sep '21

01 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=8375 --- Comment #4 from geert.hendrickx(a)telenetgroup.be <geert.hendrickx(a)telenetgroup.be> --- Hi I can reproduce exactly the same behaviour with OpenLDAP 2.5.7, on a freshly slapadd'ed mdb. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9658] New: libldap fails to compile on Hurd: MAXPATHLEN undeclared
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9658 Issue ID: 9658 Summary: libldap fails to compile on Hurd: MAXPATHLEN undeclared Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- OpenLDAP 2.5 and later fails to compile on GNU/Hurd: libtool: compile: cc -g -O2 -I../../include -I../../include -DLDAP_LIBRARY -c request.c -fPIC -DPIC -o .libs/request.o In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ Makefile:435: recipe for target 'request.lo' failed make[2]: *** [request.lo] Error 1 This is not the same as ITS#9648. I have pulled latest master and the patch for that one does not solve it. GNU/Hurd actually does not have a MAXPATHLEN constant at all; paths are expected to be dynamically allocated. See: https://www.gnu.org/software/hurd/hurd/porting/guidelines.html#PATH_MAX_tt_… This is a low priority issue for me personally. I'm just filing it for tracking. I'm hoping someone from the GNU/Hurd community might be able to work on a patch. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #7 from Ondřej Kuzník <ondra(a)mistotebe.net> --- It seems this is limited to slapd main.c so a standalone lloadd keeps the original logging configuration/code/format. Maybe the logging code could move to a separate file so it can be shared between the two. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9657] New: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry)
by openldap-its＠openldap.org 31 Aug '21

31 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9657 Issue ID: 9657 Summary: Different access privileges required for SIMPLE BIND (attr: userPassword) and SASL BIND (whole entry) Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I configure a database with: dn: cn=config objectClass: olcGlobal cn: config olcAuthzRegexp: uid=([^@,]+)(@aegee.org)?(,cn=aegee.org)?,cn=[^,]*,cn=auth uid=$1,ou=persons,o=AEGEE olcSaslSecProps: none ####################################################################### # LMDB database definitions ####################################################################### # dn: olcDatabase=mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: mdb olcDbMaxSize: 10485760 olcSuffix: o=AEGEE olcRootDN: uid=zzz,ou=persons,o=AEGEE olcRootPW: zzz olcDbDirectory: /home/d/ldap/aegee olcDbIndex: objectClass eq olcAccess: to dn.one="ou=persons,o=AEGEE" attrs=userPassword by anonymous auth olcAccess: to dn.one="ou=persons,o=AEGEE" by self read fill the database with /usr/local/bin/ldapadd -x -w zzz -D "uid=zzz;ou=persons;o=AEGEE" -H ldap://localhost <<ABC dn:o=AEGEE o:AEGEE objectClass:organization telephoneNumber:+32 2 246 0320 street:Rue du Noyer / Notelaarsstraat 55 st:Brussels postalAddress:Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium dn:ou=persons,o=AEGEE objectClass:organizationalUnit description:AEGEE members (persons) with account at https://my.aegee.eu/ dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail: lui.veve@zzzz userPassword:: dXAx structuralObjectClass: inetOrgPerson ABC Its content is ( slapcat -n1 -F conf/ ) ---- dn: o=AEGEE o: AEGEE objectClass: organization telephoneNumber: +32 2 246 0320 street: Rue du Noyer / Notelaarsstraat 55 st: Brussels postalAddress: Rue du Noyer / Notelaarsstraat 55, 1000 Brussels, Belgium structuralObjectClass: organization entryUUID: 223703d3-812e-405c-b57e-4233b55847c3 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.797291Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: ou=persons,o=AEGEE objectClass: organizationalUnit description: AEGEE members (persons) with account at https://my.aegee.eu/ structuralObjectClass: organizationalUnit ou: persons entryUUID: 17f8ff72-250b-4cbd-873f-340aaed2f0d9 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.802430Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z dn: uid=lui.veve,ou=persons,o=AEGEE objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson sn: Veve cn: Lui Veve uid: lui.veve employeeNumber: 444 givenName: Lui mail:: bHVpLnZldmVAenp6eiA= userPassword:: dXAx structuralObjectClass: inetOrgPerson entryUUID: 2e37d641-6865-4a08-87f9-b12653f52d12 creatorsName: uid=zzz,ou=persons,o=AEGEE createTimestamp: 20210830161645Z entryCSN: 20210830161645.806532Z#000000#000#000000 modifiersName: uid=zzz,ou=persons,o=AEGEE modifyTimestamp: 20210830161645Z ---- When I try to authenticate with SIMPLE BIND, OpenLDAP requests only access to the userPassword attribute: ldapwhoami -x -D "uid=lui.veve;ou=persons;o=AEGEE" -v -w up1 -H ldap://localhost/ logs: 612d04f3.27f67994 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=AEGEE)=0 612d04f3.27f6a83b 0x7f50731ac640 => ldap_dn2bv(272) 612d04f3.27f6cbf9 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d04f3.27f6e92a 0x7f50731ac640 <<< dnPrettyNormal: <uid=lui.veve,ou=persons,o=AEGEE>, <uid=lui.veve,ou=persons,o=aegee> 612d04f3.27f7035b 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f744d5 0x7f50731ac640 do_bind: version=3 dn="uid=lui.veve,ou=persons,o=AEGEE" method=128 612d04f3.27f77c7c 0x7f50731ac640 ==> mdb_bind: dn: uid=lui.veve,ou=persons,o=AEGEE 612d04f3.27f82a00 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f847bd 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d04f3.27f8a6f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d04f3.27f916cf 0x7f50731ac640 => mdb_entry_decode: 612d04f3.27f942bb 0x7f50731ac640 <= mdb_entry_decode 612d04f3.27f96490 0x7f50731ac640 => access_allowed: result not in cache (userPassword) 612d04f3.27f97b35 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "userPassword" requested 612d04f3.27f9ab7f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d04f3.27f9ccc7 0x7f50731ac640 => acl_get: [1] matched 612d04f3.27f9ddb2 0x7f50731ac640 => acl_get: [1] attr userPassword 612d04f3.27f9f63f 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "userPassword" requested 612d04f3.27fa0913 0x7f50731ac640 => acl_mask: to value by "", (=0) 612d04f3.27fa24a1 0x7f50731ac640 <= check a_dn_pat: anonymous 612d04f3.27fa492f 0x7f50731ac640 <= acl_mask: [1] applying auth(=xd) (stop) 612d04f3.27fa5bbd 0x7f50731ac640 <= acl_mask: [1] mask: auth(=xd) 612d04f3.27fa721c 0x7f50731ac640 => slap_access_allowed: auth access granted by auth(=xd) 612d04f3.27fa8306 0x7f50731ac640 => access_allowed: auth access granted by auth(=xd) 612d04f3.27fa9f20 0x7f50731ac640 conn=1001 op=0 BIND dn="uid=lui.veve,ou=persons,o=AEGEE" mech=SIMPLE bind_ssf=0 ssf=0 612d04f3.27fb0385 0x7f50731ac640 do_bind: v3 bind: "uid=lui.veve,ou=persons,o=AEGEE" to "uid=lui.veve,ou=persons,o=AEGEE" When I try to SASL connect, then OpenLDAP requests access to the whole uid=lui.veve,ou=persons,o=AEGEE entry: ldapwhoami -Y LOGIN -U"lui.veve" -v -w up1 -H ldap://localhost/ logs: 612d053d.03ab64b8 0x7f50731ac640 => ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE,0) 612d053d.03abb462 0x7f50731ac640 <= ldap_bv2dn(uid=lui.veve,ou=persons,o=AEGEE)=0 612d053d.03abddda 0x7f50731ac640 => ldap_dn2bv(272) 612d053d.03abf0ad 0x7f50731ac640 <= ldap_dn2bv(uid=lui.veve,ou=persons,o=aegee)=0 612d053d.03ac070c 0x7f50731ac640 <<< dnNormalize: <uid=lui.veve,ou=persons,o=aegee> 612d053d.03ac2626 0x7f50731ac640 <==slap_sasl2dn: Converted SASL name to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac68fe 0x7f50731ac640 slap_sasl_getdn: dn:id converted to uid=lui.veve,ou=persons,o=aegee 612d053d.03ac82e9 0x7f50731ac640 SASL Canonicalize [conn=1002]: slapAuthcDN="uid=lui.veve,ou=persons,o=aegee" 612d053d.03acd965 0x7f50731ac640 => mdb_search 612d053d.03ada119 0x7f50731ac640 mdb_dn2entry("uid=lui.veve,ou=persons,o=aegee") 612d053d.03adcf7a 0x7f50731ac640 => mdb_dn2id("uid=lui.veve,ou=persons,o=aegee") 612d053d.03ae10f4 0x7f50731ac640 <= mdb_dn2id: got id=0x3 612d053d.03ae33e0 0x7f50731ac640 => mdb_entry_decode: 612d053d.03ae6313 0x7f50731ac640 <= mdb_entry_decode 612d053d.03ae845b 0x7f50731ac640 => access_allowed: auth access to "uid=lui.veve,ou=persons,o=AEGEE" "entry" requested 612d053d.03aea02f 0x7f50731ac640 => dn: [1] ou=persons,o=aegee 612d053d.03aeba1a 0x7f50731ac640 => acl_get: [1] matched 612d053d.03aed0bf 0x7f50731ac640 => dn: [2] ou=persons,o=aegee 612d053d.03aee392 0x7f50731ac640 => acl_get: [2] matched 612d053d.03aef47c 0x7f50731ac640 => acl_get: [2] attr entry 612d053d.03af0c39 0x7f50731ac640 => acl_mask: access to entry "uid=lui.veve,ou=persons,o=AEGEE", attr "entry" requested 612d053d.03af2f6a 0x7f50731ac640 => acl_mask: to all values by "", (=0) 612d053d.03af45c9 0x7f50731ac640 <= check a_dn_pat: self 612d053d.03af513f 0x7f50731ac640 <= acl_mask: no more <who> clauses, returning =0 (stop) 612d053d.03af626f 0x7f50731ac640 => slap_access_allowed: auth access denied by =0 612d053d.03af7a71 0x7f50731ac640 => access_allowed: no more rules This is inconsistent. SASL bind shall also request only AUTH access to the userPassword, just as SIMPLE BIND does. Moreover, https://www.openldap.org/doc/admin25/access-control.html#Basic%20ACLs does suggest: Generally one should start with some basic ACLs such as: access to attrs=userPassword by self =xw by anonymous auth by * none access to * by self write by users read by * none So the suggestion is to grant "by anonymous auth" access only to attrs=userPassword , before granting any other access. If I change to olcAccess: to dn.one="ou=persons,o=AEGEE" by self read by anonymous auth then both SASL BIND and SIMPLE BIND work. Version 2.5.7-g22d1c5954e8629b. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9655] New: Expose the SNI hostname to olcAccess
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9655 Issue ID: 9655 Summary: Expose the SNI hostname to olcAccess Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- Since OpenLDAP now supports SNI, it apparently knows to which Host the client has connected, when the server is reachable under many names. • Expose the negotiated hostname to oclAccess and provide example how to limit the namingContext on the root DSE based on the requested host Rationale: HTTP servers offer the concept of virtual domains, where they serve different content behind the same IP, based on the Host: header. I want to offer public, anonymous LDAP access, but the returned results shall be completely different, and depend on the contacted host. The statements in the <WHO> field peername=<peername>, sockname=<sockname>, domain=<domain>, and sockurl=<sockurl> are evaluated only based on the contacting system (do not depend on the requested domain). (Maybe the “contacting sockurl” can do this, but this is not very clear from the documentation). So they serve similar purpose, but ignore SNI. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9654] New: Allow using both Elliptic curves and RSA certificate
by openldap-its＠openldap.org 30 Aug '21

30 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9654 Issue ID: 9654 Summary: Allow using both Elliptic curves and RSA certificate Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- sendmail and Cyrus IMAP allow to set two TLS server certificates -one RSA and EC. When the client supports Elliptic curves, the smaller EC certificate is used. Likewise it accepts two private keys, in case the private key is not included in the certificate file. In sendmail and Cyrus IMAP, two certificates are set in the same directive, separated with comma: define(`confSERVER_CERT', `/etc/zzz/fullchain.pem,/etc/zzz/fullchain_ec.pem') define(`confSERVER_KEY', `/etc/zzz/privkey.pem,/etc/zzz/privkey_ec.pem') In Cyrus IMAP the code dealing with this for OpenSSL is at https://github.com/cyrusimap/cyrus-imapd/blob/master/imap/tls.c#L453 : cf1/kf1 is the fist public/private key, cf2/kf2 are the second. In sendmail the code is in sendmail/tls.c:inittls() - it calls SSL_CTX_use_PrivateKey_file twice - once with keyfile and once with kf2 (keyfile 2). • Extend OpenLDAP to accept several certificates (RSA/EC) - either per permitting several (comma separated) values in olcTLSCertificateFile/olcTLSCertificateKeyFile , or by allowing several occurrences of the property. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9587] New: Admin guide: Need example partial replication configuration
by openldap-its＠openldap.org 27 Aug '21

27 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9587 Issue ID: 9587 Summary: Admin guide: Need example partial replication configuration Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide states: Syncrepl supports partial, sparse, and fractional replications but there are no example configurations for partial replication to draw from. This needs to be added to the guide. -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • c4d399c2 by Quanah Gibson-Mount at 2021-08-26T15:43:24+00:00 ITS#9156 - Remove ppolicy.schema from README Also remove nadf.schema, that got removed some time long ago -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to Quanah Gibson-Mount from comment #6) > (In reply to dpa-openldap(a)aegee.org from comment #5) > > For me “as large a value as possible…” sounds without “a” better. > > Then it would no longer be grammatically correct. > > "as large a value as possible" is correct. An alternative way to phrase it would be "as large of a value as possible", but both are correct statements. "as large value as possible" is not a correct statement in any form in this context. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #5) > For me “as large a value as possible…” sounds without “a” better. Then it would no longer be grammatically correct. "as large a value as possible" is correct. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #5 from dpa-openldap(a)aegee.org <dpa-openldap(a)aegee.org> --- For me “as large a value as possible…” sounds without “a” better. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- (In reply to dpa-openldap(a)aegee.org from comment #3) > How about this sentence: > > > It is important to set this to as large a value as possible… What about it? It's a correct statement. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8862] typos manual slapd-mdb
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8862 --- Comment #3 from dpa-openldap(a)aegee.org <dpa-openldap(a)aegee.org> --- How about this sentence: > It is important to set this to as large a value as possible… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 26 Aug '21

26 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mhardin(a)symas.com --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9492 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 6097] MMR problems with deletes
by openldap-its＠openldap.org 24 Aug '21

24 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6097 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9647 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 19 Aug '21

19 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=6097 --- Comment #4 from Ondřej Kuzník <ondra(a)mistotebe.net> --- So testing confirms the systems converge right now, extremely noisily (the add or delete fails, we go into refresh, etc.) but things settle in the right way (the parent is removed (made into glue) and the child remains. There are situation where is fails but those are bugs (to be) filed separately. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9628] New: Incorrect handling of c_n_ops_executing counter when using an asynchronous backend (back-asyncmeta)
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9628 Issue ID: 9628 Summary: Incorrect handling of c_n_ops_executing counter when using an asynchronous backend (back-asyncmeta) Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: nivanova(a)symas.com Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9611] New: no structural objectclass in configuration table
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9611 Issue ID: 9611 Summary: no structural objectclass in configuration table Product: OpenLDAP Version: 2.5.5 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: jb00356987(a)techmahindra.com Target Milestone: --- Dears, When I tried to start sldap 2.5.5 I get following error : 60eff599.06749e9d 0x7fb62750f740 <<< dnNormalize: <cn=manager,cn=config> 60eff599.0674bad5 0x7fb62750f740 <= str2entry(cn=module{0}) -> 0x1193828 60eff599.06752650 0x7fb62750f740 : config_add_internal: DN="cn=module{0},cn=config" no structural objectClass in configuration table 60eff599.06753c3c 0x7fb62750f740 config error processing cn=module{0},cn=config: 60eff599.0675a8bc 0x7fb62750f740 send_ldap_result: conn=-1 op=0 p=0 60eff599.067611e4 0x7fb62750f740 build-corp-M1 destroy: freeing system resources. 60eff599.06767673 0x7fb62750f740 slapd stopped. 60eff599.06770970 0x7fb62750f740 connections_destroy: nothing to destroy. I don't understand why I get it as I'm able to run slapd 2.4.59 with same config/DB. Can you advice ? Thx, J-L. -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9569] New: objectClass Violation with lastbind and delta-syncrepl
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9569 Issue ID: 9569 Summary: objectClass Violation with lastbind and delta-syncrepl Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gnoe(a)symas.com Target Milestone: --- If olcLastBind is set to true in a delta-syncrepl environment, slapd fails to add auditModify entries for lastbind to the accesslog due to an objectClass violation. The auditModify object lacks the required reqMod attributes. The lastbind module is not in use. The ppolicy overlay is also in use. It shows in the slapd log as: Jun 03 13:05:34 l-02992-d5a slapd[18715]: Entry(reqStart=20210603170529.000262Z,cn=accesslog): object class 'auditModify' requires attribute 'reqMod' Jun 03 13:05:34 l-02992-d5a slapd[18715]: accesslog_response: got result 0x41 adding log entry reqStart=20210603170529.000262Z,cn=accesslog -- You are receiving this mail because: You are on the CC list for the issue.

1 15

[Issue 9625] New: ppolicy: spamming log
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9625 Issue ID: 9625 Summary: ppolicy: spamming log Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Noticed on a few recent deployments that ppolicy is spamming the logs with: ppolicy_bind: Setting warning for password expiry <DN> = 0 second on every bind. Haven't noticed this in the past but the code has been like this since 2004. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9624] New: Issues in client state tracking
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9624 Issue ID: 9624 Summary: Issues in client state tracking Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- There are two places that don't track client state (BINDING/OPEN) correctly: - handle_one_request() reads c_state/c_io_state without holding the appropriate mutex - operation_unlink_client() assumes that if state is BINDING, the operation we're just unlinking is a bind request. However the client could have sent another operation without waiting for the bind response, we shouldn't touch state when disposing of those -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9549] New: ldapvc needs a man page
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9549 Issue ID: 9549 Summary: ldapvc needs a man page Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The ldapvc tool was added in 2.5, but there is no man page for it yet. I've opened this as a separate ITS, rather than append to ITS#9284, because ldapvc is not in contrib and is always installed. -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9443] New: Admin guide: Need section on lloadd and load balancer as slapd module
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9443 Issue ID: 9443 Summary: Admin guide: Need section on lloadd and load balancer as slapd module Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: blocker Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide currently has no documentation on the new lloadd daemon or the ability to set up the load balancer as a module inside of slapd. This is a release requirement. -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 9637] New: back-mdb idlexp max is 30, not 31
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9637 Issue ID: 9637 Summary: back-mdb idlexp max is 30, not 31 Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Even so, it's ridiculous to use 2 billion slot IDLs (16GB each) unless you have hundreds of GB of RAM. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9630] New: back-sql leaves db transaction open after a bind or search operation
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9630 Issue ID: 9630 Summary: back-sql leaves db transaction open after a bind or search operation Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: aapo.romu(a)eficode.com Target Milestone: --- Created attachment 833 --> https://bugs.openldap.org/attachment.cgi?id=833&action=edit Close transactions after bind or search operation back-sql leaves db transaction open after a bind or search operation. This prevents ie. PostgreSQL to perform VACUUM operations and seems also contribute to decreased performance. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9621] New: back-mdb multival NULL matchingrule crash
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9621 Issue ID: 9621 Summary: back-mdb multival NULL matchingrule crash Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When configured for multival, back-mdb may crash if the attribute schema has no equality matching rule. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9629] New: When configuring ppolicy with back-sql backend ppolicy rules are not obeyed
by openldap-its＠openldap.org 18 Aug '21

18 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9629 Issue ID: 9629 Summary: When configuring ppolicy with back-sql backend ppolicy rules are not obeyed Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: aapo.romu(a)eficode.com Target Milestone: --- Created attachment 832 --> https://bugs.openldap.org/attachment.cgi?id=832&action=edit Patch for processing the needed op attributes to make ppolicy work When configuring ppolicy with back-sql backend ppolicy rules are not obeyed. The back-sql does not process op attributes at all so it misses the ppolicy configuration -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Bug 9200] New: 2.4 to 2.5 upgrade documentation
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9200 Bug ID: 9200 Summary: 2.4 to 2.5 upgrade documentation Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: blocker Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For the 2.5 release, we need to document the upgrade procedures for moving from OpenLDAP 2.4 to OpenLDAP 2.5. -- You are receiving this mail because: You are on the CC list for the bug.

1 20

[Issue 9627] New: Query regarding openldap ca cert buffer usage over filepath
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9627 Issue ID: 9627 Summary: Query regarding openldap ca cert buffer usage over filepath Product: OpenLDAP Version: 2.5.6 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: naveen.kumartg(a)siemens.com Target Milestone: --- Hi, We are unable to connect to openldap server via starttls using LDAP_OPT_X_TLS_CACERT. The LDAP_OPT_X_TLS_CACERT option doesn't work and it is not mentioned in any of the documents. LDAP_OPT_X_TLS_CACERTFILE option does work but it takes file path. Does openldap stack support ca certificate in buffer/array format otherthan just the filepath.?, We would like to avoid filepath. Best Regards, Naveen -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 5344] Wrong check for bad Modify DN
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=5344 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 49ee5d9b by Howard Chu at 2021-08-13T21:09:28+01:00 ITS#5344 slapo-rwm: fix prev commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9122] slapadd with dry run fails with back-mdb
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9122 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 973a9303 by Howard Chu at 2021-08-13T02:09:48+00:00 ITS#9122 expose SLAP_TOOL_DRYRUN to backends -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8958 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #41 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 5ad6ab35 by Howard Chu at 2021-08-12T18:59:06+00:00 ITS#8958 rename ldap_pvt_thread_pool_pausecheck() • f6a61ab7 by Howard Chu at 2021-08-12T18:59:06+00:00 ITS#8958 back-mdb: checkpoint online indexer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9634] New: ACL processing of <what> clauses should evaluate regex pattern after other variants
by openldap-its＠openldap.org 16 Aug '21

16 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9634 Issue ID: 9634 Summary: ACL processing of <what> clauses should evaluate regex pattern after other variants Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Evaluating regex patterns cost performance. Thus cheaper <what> parts (e.g. attrs=) should be evaluated before dn.regex= and val.regex=. Likely evaluating simple dn.(sub|one|exact) should be split from processing dn.regex. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9122] slapadd with dry run fails with back-mdb
by openldap-its＠openldap.org 11 Aug '21

11 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9122 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Status|UNCONFIRMED |IN_PROGRESS --- Comment #4 from Howard Chu <hyc(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/375 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9122] slapadd with dry run fails with back-mdb
by openldap-its＠openldap.org 09 Aug '21

09 Aug '21

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

1 0

[Issue 9626] New: Segmentation fault on mdb_midl_append_list
by openldap-its＠openldap.org 09 Aug '21

09 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=9626 Issue ID: 9626 Summary: Segmentation fault on mdb_midl_append_list Product: LMDB Version: 0.9.29 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: carlos.velasco(a)nimastelecom.com Target Milestone: --- Hello, Using LMDB for modsecurity 3 I get segmentation fauls of httpd every few hours. Core debugging shows it ocurrs in mdb_midl_append_list in LMDB lib. # gdb /usr/sbin/httpd core.httpd.25.127c0e0a8a1e468f8d5749d995f81381.204107.1628497829000000000000 GNU gdb (GDB) 9.2 Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-pc-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <http://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /usr/sbin/httpd... (No debugging symbols found in /usr/sbin/httpd) [New LWP 204177] [New LWP 204154] [New LWP 204152] [New LWP 204151] [New LWP 204107] [New LWP 204169] [New LWP 204147] [New LWP 204149] [New LWP 204170] [New LWP 204173] [New LWP 204186] [New LWP 204185] [New LWP 204181] [New LWP 204189] [New LWP 204184] [New LWP 204171] [New LWP 204172] [New LWP 204178] [New LWP 204175] [New LWP 204187] [New LWP 204174] [New LWP 204176] [New LWP 204179] [New LWP 204180] [New LWP 204182] [New LWP 204183] [New LWP 204188] [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Core was generated by `/usr/sbin/httpd -k start'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007f2a32a4109f in mdb_midl_append_list (idp=0x7f29f8041b13, app=0x25fa538) at midl.c:175 175 midl.c: No such file or directory. [Current thread is 1 (Thread 0x7f2a09ffb640 (LWP 204177))] (gdb) bt #0 0x00007f2a32a4109f in mdb_midl_append_list (idp=0x7f29f8041b13, app=0x25fa538) at midl.c:175 #1 0x00007f2a32a325bf in mdb_txn_commit (txn=0xf9bda0) at mdb.c:3485 #2 0x00007f2a32eb8904 in modsecurity::collection::backend::LMDB::storeOrUpdateFirst (this=0x1fe28b0, key=..., value=...) at collection/backend/lmdb.cc:245 #3 0x00007f2a32e97bb8 in modsecurity::collection::Collection::storeOrUpdateFirst (value=..., compartment2=..., compartment=..., key=..., this=0x1fe28b0) at ../headers/modsecurity/collection/collection.h:99 #4 modsecurity::variables::Ip_DynamicElement::storeOrUpdateFirst (value=..., var=..., t=<optimized out>) at ../src/variables/ip.h:110 #5 modsecurity::actions::SetVar::evaluate (this=0x30acfc0, rule=<optimized out>, t=<optimized out>) at actions/set_var.cc:144 #6 0x00007f2a32e641bc in modsecurity::RuleWithActions::executeActionsIndependentOfChainedRuleResult (this=this@entry=0x30c9f50, trans=trans@entry=0x7f29f8036e40, containsBlock=containsBlock@entry=0x7f2a09ff94ef, ruleMessage=...) at rule_with_actions.cc:199 #7 0x00007f2a32e6dc33 in modsecurity::RuleWithOperator::evaluate (this=<optimized out>, trans=<optimized out>, ruleMessage=...) at /usr/include/c++/11.2.0/ext/atomicity.h:109 #8 0x00007f2a32e66e59 in modsecurity::RuleWithActions::evaluate (this=0x30c9f50, transaction=0x7f29f8036e40) at /usr/include/c++/11.2.0/ext/atomicity.h:111 #9 0x00007f2a32e5cd3c in modsecurity::RulesSet::evaluate (this=<optimized out>, phase=phase@entry=3, t=t@entry=0x7f29f8036e40) at rules_set.cc:210 #10 0x00007f2a32e41793 in modsecurity::Transaction::processRequestBody (this=0x7f29f8036e40) at transaction.cc:942 #11 0x00007f2a32fa0a28 in hook_request_late () from /usr/lib64/httpd/modules/mod_security3.so #12 0x000000000045616b in ap_process_request_internal () #13 0x0000000000476ef3 in ap_process_async_request () #14 0x0000000000473150 in ap_process_http_connection () #15 0x00000000004695bf in ap_run_process_connection () #16 0x00007f2a33492831 in process_socket () from /usr/lib64/httpd/modules/mod_mpm_event.so #17 0x00007f2a33493307 in worker_thread () from /usr/lib64/httpd/modules/mod_mpm_event.so #18 0x00007f2a33703fd6 in start_thread () from /lib64/libpthread.so.0 #19 0x00007f2a336241df in clone () from /lib64/libc.so.6 (gdb) Regards, Carlos Velasco -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 06 Aug '21

06 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8958 --- Comment #40 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE25 commit: 2.5 slapcat compat with 2.4 dbs: Commits: • d00efea7 by Howard Chu at 2021-08-06T21:54:44+00:00 (From ITS#8958) allow 2.5 slapcat to read 2.4 DB -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8958] 2nd cn=config update blocks slapd while adding subordinate index
by openldap-its＠openldap.org 06 Aug '21

06 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=8958 --- Comment #39 from Quanah Gibson-Mount <quanah(a)openldap.org> --- 2.5 compat with 2.4 dbs: Commits: • d877251b by Howard Chu at 2021-08-06T22:50:23+01:00 (From ITS#8958) allow 2.5 slapcat to read 2.4 DB -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 5344] Wrong check for bad Modify DN
by openldap-its＠openldap.org 06 Aug '21

06 Aug '21

https://bugs.openldap.org/show_bug.cgi?id=5344 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 1cf39a85 by Ondřej Kuzník at 2021-08-06T15:30:47+01:00 ITS#5344 Record and maintain new DN on ModRDN ops -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs