August 2020 - openldap-bugs

[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9222 Bug ID: 9222 Summary: Fix presence list to use a btree instead of an AVL tree 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: --- [23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal [23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh [23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist [23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs [23:36] <hyc> being stored in an avl tree [23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array [23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase [00:05] <hyc> this stuff seriously needs a rewrite [01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead [01:13] <hyc> and instead it's 3-400MB -- You are receiving this mail because: You are on the CC list for the bug.

1 day, 21 hours

1
4
0 / 0

[Issue 9277] New: restart 3+ providers at once burns CPU forever

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9277 Issue ID: 9277 Summary: restart 3+ providers at once burns CPU forever Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I have tiny VMs configured as Æ-DIR servers, 5 providers (multi-provider replication) and 5 read-only consumers each syncing with all providers. Restarting all consumers at once simply works, no matter how many of the providers are up. Restarting only two providers at once also works. But when restarting more than two providers at once all of thems seem to hang eating up CPU. It could be the same issue like ITS#8650 / ITS#9210 but those only mention GNUTLS being affected. But all my Æ-DIR test servers run slapd built against OpenSSL (openSUSE, Debian buster, CentOS7). -- You are receiving this mail because: You are on the CC list for the issue.

3 days, 13 hours

1
5
0 / 0

[Issue 9293] New: slapo-ppolicy stores pwdGraceUseTime only with seconds

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9293 Issue ID: 9293 Summary: slapo-ppolicy stores pwdGraceUseTime only with seconds Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- If password is expired slapo-ppolicy can return the number of grace logins for changing own password (graceAuthNsRemaining). slapd derives graceAuthNsRemaining from number of pwdGraceUseTime values. But those timestamps are only stored with a granularity of a second. Thus multiple grace logins are possible within a second without decremeting graceAuthNsRemaining value. This is unexpected and also leads to absurd work-arounds when writing automated tests like this: https://gitlab.com/ae-dir/python-ldap0/-/blob/master/tests/test_ppolicy.p... Either a real Integer counter should be used or fraction of seconds should be used in pwdGraceUseTime values. This is a similar problem like pwdFailureTime solved in ITS#7161. -- You are receiving this mail because: You are on the CC list for the issue.

3 days, 13 hours

1
2
0 / 0

[Issue 9327] New: Stripping when cross-compiling

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9327 Issue ID: 9327 Summary: Stripping when cross-compiling Product: OpenLDAP Version: unspecified Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: fontaine.fabrice(a)gmail.com Target Milestone: --- Created attachment 756 --> https://bugs.openldap.org/attachment.cgi?id=756&action=edit Patch When cross-compiling, stripping fails because strip is used instead of $(STRIP). The attached patch (retrieved from https://git.buildroot.net/buildroot/tree/package/openldap/0001-fix_cross_...) fix this issue. I've also opened a Merge Request: https://git.openldap.org/openldap/openldap/-/merge_requests/101 -- You are receiving this mail because: You are on the CC list for the issue.

4 days, 11 hours

1
3
0 / 0

[Issue 9317] New: LDAPS connection fails to multi-IP DNS using DIGEST-MD5 mechanism

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9317 Issue ID: 9317 Summary: LDAPS connection fails to multi-IP DNS using DIGEST-MD5 mechanism Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: paul.raines(a)gmail.com Target Milestone: --- Our MS AD ldap servers are in DNS using alias ldap.example.org at multiple IP addresses like so: # host ldap.example.org ldap.example.org has address 172.18.1.10 ldap.example.org has address 172.21.1.10 ldap.example.org has address 172.24.1.10 ldap.example.org has address 172.30.1.10 For CentOS 6 this was not a problem. But with CentOS 7 (2.4.44) and CentOS 8 (2.4.46) the following fails # ldapwhoami -d -1 -H ldaps://ldap.example.org -Y DIGEST-MD5 -U username -W with the error: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090303: LdapErr: DSID-0C090574, comment: The digest-uri does not match any LDAP SPN's registered for this server., data 0, v3839 ldap_free_connection 1 1 ldap_send_unbind If one reverse DNS IP lookups one of the IPs and uses the unique name (e.g. ldap01.example.org) instead it works fine I think openldap should work in this case with DNS aliases. -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

1
3
0 / 0

[Issue 9315] New: FR: Support SPIFFE Certificate Provisioner

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9315 Issue ID: 9315 Summary: FR: Support SPIFFE Certificate Provisioner Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: dar(a)xoe.solutions Target Milestone: --- Created attachment 754 --> https://bugs.openldap.org/attachment.cgi?id=754&action=edit A SPIFFE samle certificate SPIFFE is a protocol for attesting workload identities. It implements a pull based workflow where clients request ad-hoc certificates about their identity from a unix domain socket. While there is a helper that can wrap clients it is uncertain how certificate rolls, which happen by default every few minutes, shall be signalled to the ldap client: https://github.com/spiffe/spiffe-helper I assume there is no signal which induces graceful reloading of the certificates. Therefore, it might be considerable adding direct spiffe support to the ldap client. See example: https://github.com/spiffe/c-spiffe/blob/master/c-spiffe.cc Please find attached a spiffe sample cert, for mere information. Note it does convey identity (exclusively) through SAN, which currently seems not be supported in OpenLDAP. I'm going to open another issue for that. -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

1
3
0 / 0

[Issue 9310] New: slapd segmends when creating a new mdb database

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9310 Issue ID: 9310 Summary: slapd segmends when creating a new mdb database Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: p.childs(a)qmul.ac.uk Target Milestone: --- I'm attempting to upgrade out current openldap server from our rather old openldap running under SL6 onto something slightly more modern. I'm looking to start using multimaster and mdb rather than bdb etc etc. When I try and enable delta-replication to use mdb using I'm getting a segmentation fault. Thanks in advance. Peter Childs [ 5375.411805] slapd[8207]: segfault at 50 ip 00007fdf8846eb6c sp 00007fdf6da4cc90 error 4 in liblber-2.4.so.2.10.13[7fdf88466000+e000] 5f311f55 send_ldap_result: err=0 matched="" text="" 5f311f55 connection_get(15) 5f311f55 conn=1000 op=1 do_add: dn (olcDatabase={3}mdb,cn=config) => ldap_bv2dn(olcDatabase={3}mdb,cn=config,0) <= ldap_bv2dn(olcDatabase={3}mdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase={3}mdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcDatabase={3}mdb,cn=config)=0 => ldap_bv2dn(cn=accesslog,0) <= ldap_bv2dn(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_bv2dn(cn=accesslog,0) <= ldap_bv2dn(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_bv2dn(cn=accesslog,0) <= ldap_bv2dn(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5f311f55 register_at: AttributeType "( olmMDBAttributes:1 NAME ( 'olmMDBPagesMax' ) DESC 'Maximum number of pages' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation )": Inconsistent duplicate attributeType, 5f311f55 mdb_monitor_initialize: register_at failed for attributeType (( olmMDBAttributes:1 NAME ( 'olmMDBPagesMax' ) DESC 'Maximum number of pages' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation )) => ldap_bv2dn(cn=accesslog,0) <= ldap_bv2dn(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_bv2dn(cn=accesslog,0) <= ldap_bv2dn(cn=accesslog)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=accesslog)=0 => ldap_bv2dn(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk,0) <= ldap_bv2dn(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk)=0 => ldap_bv2dn(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk,0) <= ldap_bv2dn(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk)=0 => ldap_bv2dn(cn=config,0) <= ldap_bv2dn(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(cn=config)=0 5f311f55 mdb_db_open: "cn=accesslog" Segmentation fault (core dumped) this is after apply the following ldif dn: olcDatabase={3}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {3}mdb olcDbDirectory: /var/lib/ldap-accesslog olcSuffix: cn=accesslog olcAccess: {0}to dn.subtree="cn=accesslog" by dn.exact="cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk" read olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=config olcLimits: dn.exact="cn=replica,dc=hpc,dc=qmul,dc=ac,dc=uk" time=unlimited size=unlimited olcSizeLimit: unlimited olcTimeLimit: unlimited olcMonitoring: TRUE olcDbCheckpoint: 0 0 olcDbIndex: entryCSN eq olcDbIndex: objectClass eq olcDbIndex: reqEnd eq olcDbIndex: reqResult eq olcDbIndex: reqStart eq olcDbIndex: reqDN eq olcDbMode: 0600 olcDbSearchStack: 16 olcDbMaxsize: 85899345920 -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

1
5
0 / 0

[Issue 9306] New: clang UndefinedBehaviorSanitizer report

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9306 Issue ID: 9306 Summary: clang UndefinedBehaviorSanitizer report Product: LMDB Version: 0.9.24 Hardware: x86_64 OS: Mac OS Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: AskAlexSharov(a)gmail.com Target Milestone: --- Hello. We using LMDB from Golang application. Clang compiler with flag "-fsanitize=undefined" shows next report: mdb.c:7544:26: runtime error: member access within misaligned address 0x00d24759d53a for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x00d24759d53a: note: pointer points here 00 00 00 01 c4 49 00 01 00 00 00 00 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7544:26 in mdb.c:7544:26: runtime error: member access within misaligned address 0x00d24759d546 for type 'union (anonymous union at mdb.c:826:2)', which requires 4 byte alignment 0x00d24759d546: note: pointer points here 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 c8 00 20 00 00 00 00 00 00 00 21 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7544:26 in mdb.c:7544:26: runtime error: member access within misaligned address 0x00d24759d546 for type 'struct (anonymous struct at mdb.c:827:3)', which requires 4 byte alignment 0x00d24759d546: note: pointer points here 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 c8 00 20 00 00 00 00 00 00 00 21 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7544:26 in mdb.c:7544:26: runtime error: load of misaligned address 0x00d24759d546 for type 'indx_t' (aka 'unsigned short'), which requires 4 byte alignment 0x00d24759d546: note: pointer points here 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 c8 00 20 00 00 00 00 00 00 00 21 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7544:26 in mdb.c:7545:3: runtime error: member access within misaligned address 0x00d24759d53a for type 'MDB_page' (aka 'struct MDB_page'), which requires 8 byte alignment 0x00d24759d53a: note: pointer points here 00 00 00 01 c4 49 00 01 00 00 00 00 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7545:3 in mdb.c:7545:3: runtime error: member access within misaligned address 0x00d24759d53a for type 'union (anonymous union at mdb.c:802:2)', which requires 8 byte alignment 0x00d24759d53a: note: pointer points here 00 00 00 01 c4 49 00 01 00 00 00 00 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 ^ SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior mdb.c:7545:3 in mdb.c:7545:3: runtime error: load of misaligned address 0x00d24759d53a for type 'pgno_t' (aka 'unsigned long'), which requires 8 byte alignment 0x00d24759d53a: note: pointer points here 00 00 00 01 c4 49 00 01 00 00 00 00 00 00 52 00 20 00 20 00 6a 01 2e 01 f2 00 4a 00 9e 00 74 00 ^ -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

1
3
0 / 0

[Issue 9286] New: mdb_cursor_get MDB_GET_MULTIPLE key not populated

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9286 Issue ID: 9286 Summary: mdb_cursor_get MDB_GET_MULTIPLE key not populated Product: LMDB Version: 0.9.25 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: corey(a)kaylors.net Target Milestone: --- Reading the docs it says "Return key and up to a page of duplicate data items from current cursor position." when MDB_GET_MULTIPLE is used. I don't see the key being populated, but when I call MDB_GET_CURRENT after the use of MDB_GET_MULTIPLE the key is the value I expect. Looking through the code I don't see the key getting used in this path. Granted, I'm not proficient with C so I may have overlooked something. -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

2
5
0 / 0

[Issue 9268] New: Test065 fails due to invalid log level

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9268 Issue ID: 9268 Summary: Test065 fails due to invalid log level Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: andy(a)asjohnson.com Target Milestone: --- Line #109 of tests/scripts/test065-proxyauthz: $SLAPD -f $CONF2 -h $URI2 -d $LVL -d pcache > $LOG2 2>&1 & Results in this: must compile with LDAP_DEBUG for debugging unrecognized log level "pcache" (deferred) After which the test fails. -- You are receiving this mail because: You are on the CC list for the issue.

1 week, 1 day

1
4
0 / 0

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2020