openldap-bugs September 2020

openldap-bugs@openldap.org

4 participants
305 discussions

[Issue 9327] New: Stripping when cross-compiling
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

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_st…) 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.

1 10

[Issue 9283] New: Mutex leak in backend.c`backend_db_init()
by openldap-its＠openldap.org 25 Feb '21

25 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9283 Issue ID: 9283 Summary: Mutex leak in backend.c`backend_db_init() Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- @backend_db_init: if bi_db_init() fails, but [BackendDB *be] is not listed in [slap_be_head backendDB] list of backends, then be->be_pcl_mutex is not destroyed. | BackendDB * | backend_db_init( ... ) | { | ... | ldap_pvt_thread_mutex_init( &be->be_pcl_mutex ); | ... | if ( bi->bi_db_init ) | rc = bi->bi_db_init( be, cr ); | | if ( rc != 0 ) { | if ( !b0 ) { | ... | ldap_pvt_thread_mutex_destroy( &be->be_pcl_mutex ); | ch_free( be ); Additionally, it does not look like that owner of [b0] cares about destroying this mutex. -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9293] New: slapo-ppolicy stores pwdGraceUseTime only with seconds
by openldap-its＠openldap.org 24 Feb '21

24 Feb '21

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.py#… 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.

1 6

[Issue 9332] New: Compilation of 2.4.52 fails: "init.c", line 45: too many initializers for scalar
by openldap-its＠openldap.org 22 Feb '21

22 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9332 Issue ID: 9332 Summary: Compilation of 2.4.52 fails: "init.c", line 45: too many initializers for scalar Product: OpenLDAP Version: 2.4.52 Hardware: All OS: Solaris Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- The addition of integer ldo_tls_require_san to structure requires an additional initialization digit to macro LDAP_LDO_TLS_NULLARG. --- openldap-2.4.52/libraries/libldap/ldap-int.h 2020-08-28 09:10:00.000000000 -0700 +++ openldap-2.4.52.x/libraries/libldap/ldap-int.h 2020-09-01 10:08:44.661226154 -0700 @@ -263,7 +263,7 @@ int ldo_tls_impl; int ldo_tls_crlcheck; int ldo_tls_require_san; -#define LDAP_LDO_TLS_NULLARG ,0,0,0,{0,0,0,0,0,0,0,0,0},0,0,0,0 +#define LDAP_LDO_TLS_NULLARG ,0,0,0,{0,0,0,0,0,0,0,0,0},0,0,0,0,0 #else #define LDAP_LDO_TLS_NULLARG #endif -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9322] New: Update admin guide to recommend OpenSSL 1.1 as a minimum release
by openldap-its＠openldap.org 08 Feb '21

08 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9322 Issue ID: 9322 Summary: Update admin guide to recommend OpenSSL 1.1 as a minimum release Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.5, we need to update the recommended OpenSSL version to be 1.1 or later. appendix-recommended-versions.sdf -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Bug 9205] New: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap
by openldap-its＠openldap.org 01 Feb '21

01 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9205 Bug ID: 9205 Summary: Openldap 2.4.49 with overlays syncrepl+ppolicy+chain+ldap Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Created attachment 700 --> https://bugs.openldap.org/attachment.cgi?id=700&action=edit test script copied from test022-ppolicy and modified to show the trouble Hello, I'm doing a OpenLDAP test with a master/slave replication configuration including ppolicy overlay. I would like to enable password change from the slave replica with chain overlay, in order to validate the ppolicy olcPPolicyForwardUpdates attribute to TRUE. I'm using LDAPS from slave to master with SASL External authentication with client certificate. The client certificate correspond to a user DN entry with "manage" rights on the master server (the same used for the replication). This user DN has authzTo attribute in order to match the correct PROXYAUTHZ request from its dn to user DN. All of this configuration works on replica when i do first a failed authentication (err=49) on replica. The pwdFailureTime value is updated on the DN entry from replica to slave normally. I'm also able to do after some self entry update on some attribute such as password or others from replica to master. But the weird behavior is that i need to run first an failed authentication, otherwise if i try to change attribute on the slave server, it respond an err=80 "Error: ldap_back_is_proxy_authz returned 0, misconfigured URI?". The only way to retrieve correct behavior is to restart slapd, and redo one failed authentication first. It seems that the chain overlay do not connect the master server at startup. I've done a modification of test script test022-ppolicy to test022-policy-chain which use the same LDIF source and show the problem of modification on the consumer not "relayed" to the supplier if a fail operation is not done before. Regards -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Issue 9340] New: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s)
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

https://bugs.openldap.org/show_bug.cgi?id=9340 Issue ID: 9340 Summary: Setting slapd.conf listener-threads > 1 causes Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s) Product: OpenLDAP Version: 2.4.52 Hardware: Other OS: Solaris Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: stacey.marshall(a)gmail.com Target Milestone: --- Created attachment 761 --> https://bugs.openldap.org/attachment.cgi?id=761&action=edit Output from -d 5 option This is not a new issue, the same is observed on version 2.4.45 through 2.4.53 Setting listener-threads via slapd.conf file on Sun4v (SPARC T4-1) system to a value other than 1 results in "Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c" when starting slapd. The same does not occur when using Directory (-F) configuration. # grep '^listener-threads' /etc/openldap/slapd.conf listener-threads 8 # /usr/lib/slapd -u openldap -g openldap \ > -f /etc/openldap/slapd.conf \ > -h 'ldap:/// ldapi:/// ldaps:///' -d 5 > slapd.error 2>&1 Abort (core dumped) # tail slapd.error 5f578024 >>> dnNormalize: <cn=Current> 5f578024 <<< dnNormalize: <cn=current> 5f578024 >>> dnNormalize: <cn=Uptime> 5f578024 <<< dnNormalize: <cn=uptime> 5f578024 >>> dnNormalize: <cn=Read> 5f578024 <<< dnNormalize: <cn=read> 5f578024 >>> dnNormalize: <cn=Write> 5f578024 <<< dnNormalize: <cn=write> 5f578024 slapd starting Assertion failed: SLAP_SOCK_NOT_ACTIVE(id, s), file daemon.c, line 903 # /usr/lib/slapd -VVV @(#) $OpenLDAP: slapd 2.4.53 (Sep 8 2020 03:15:21) $ openldap Included static overlays: accesslog auditlog collect constraint dds deref dyngroup dynlist memberof ppolicy pcache refint retcode rwm seqmod sssvlv syncprov translucent unique valsort Included static backends: config ldif monitor ldap mdb meta null passwd relay shell # When running under debugger the issue is not observed. The core file reveals the following threads: # /opt/solarisstudio12.4/bin/dbx /usr/lib/slapd core For information about new features see `help changes' To remove this message, put `dbxenv suppress_startup_message 8.0' in your .dbxrc Reading slapd core file header read successfully Reading ld.so.1 Reading libc.so.1 Reading libldap_r-2.4.so.2.11.1 Reading liblber-2.4.so.2.11.1 Reading libsasl2.so.3.0.0 Reading liblogin.so.3.0.0 Reading libgssapiv2.so.3.0.0 Reading libgssapi_krb5.so.2.2 Reading libkrb5.so.3.3 Reading libcom_err.so.3.0 Reading libkrb5support.so.0.1 Reading libk5crypto.so.3.1 Reading libucrypto.so.1 Reading libbsm.so.1 Reading libtsol.so.2 Reading libinetutil.so.1 Reading libcryptoutil.so.1 Reading libelf.so.1 Reading libz.so.1 Reading libresolv.so.2 Reading libkwarn.so.1 Reading libplain.so.3.0.0 Reading libotp.so.3.0.0 Reading libcrypto.so.1.0.0 Reading libsasldb.so.3.0.0 Reading libdb-5.3.so Reading libscram.so.3.0.0 Reading libltdl.so.7.3.1 Reading libssl.so.1.0.0 Reading libuuid.so.1 t@2 (l@2) terminated by signal ABRT (Abort) 0x0007fdd05cce17a8: __lwp_sigqueue+0x0008: bcc,a,pt %icc,__lwp_sigqueue+0x18 ! 0x7fdd05cce17b8 (dbx) lwps l@1 LWP suspended in uucopy() o>l@2 signal SIGABRT in __lwp_sigqueue() l@3 LWP suspended in __pollsys() l@4 LWP suspended in __pollsys() l@5 LWP suspended in __pollsys() (dbx) where current thread: t@2 =>[1] __lwp_sigqueue(0x0, 0xa00386a7d98, 0x6, 0x0, 0xffffffffffffffff, 0x0), at 0x7fdd05cce17a8 [2] raise(0x6, 0x7fdd0583ff060, 0x5, 0x5, 0x0, 0x0), at 0x7fdd05cc2af0c [3] abort(0x1, 0x1210, 0x0, 0x1000, 0x7fdd05ce3c278, 0x1a278), at 0x7fdd05cbfa144 [4] _assert(0x10005d7a8, 0x10005d7c8, 0x387, 0x9, 0x8200, 0x7fdd05ce22000), at 0x7fdd05cbfb158 [5] slapd_daemon_task(0xc4, 0xffffffffffcdb7c8, 0x100382000, 0x324800, 0x61bf4f2270, 0x100406d3c), at 0x1000c118c (dbx) lwp l@1 t@1 (l@1) stopped in uucopy at 0x7fdd05cce1d34 0x0007fdd05cce1d34: uucopy+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] uucopy(0x0, 0x7fdd0553fff10, 0xb0, 0xfffffffffffffff8, 0x0, 0xfffffe59ec25a990), at 0x7fdd05cce1d34 [2] setup_top_frame(0x7fdd054c00000, 0x7fffc0, 0x7fdd0553fffc0, 0x7fdd0553fffc0, 0x0, 0xfffffe59ec25adf0), at 0x7fdd05ccdc494 [3] setup_context(0xfffffe59ec25ab10, 0x7fdd05ccdc538, 0x7fdd058492240, 0x7fdd054c00000, 0x7fffc0, 0x1), at 0x7fdd05ccdc4dc [4] _thrp_create(0x0, 0x800000, 0x1000becb0, 0x61bfa6bed0, 0x80, 0xfffffe59ec25aeb0), at 0x7fdd05ccd7f64 [5] pthread_create(0x61bfa6bed0, 0xfffffe59ec25af78, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x0), at 0x7fdd05ccc80e4 [6] ldap_pvt_thread_create(0x61bfa6bed0, 0x0, 0x1000becb0, 0x61bfa6bed0, 0x0, 0x61bfa6bec0), at 0x7fdd05c81b324 [7] slapd_daemon(0x100406db8, 0x4, 0x10042710c, 0x100389490, 0x100406d38, 0x100382000), at 0x1000c1404 [8] main(0x8800, 0x10038aa88, 0x1, 0x100386038, 0x1, 0x10038aa84), at 0x10009ec34 (dbx) lwp l@3 t@3 (l@3) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd0577ff2a0, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x10, 0x7fdd0577ffc30, 0x7fdd0577ff2a0, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x10, 0x7fdd0577ffc30, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x1, 0x1004010c8, 0x5), at 0x1000c014c (dbx) lwp l@4 t@4 (l@4) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x4, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd056bff370, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x12, 0x7fdd056bffd10, 0x7fdd056bff370, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x12, 0x7fdd056bffd10, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x2, 0x1004016f0, 0x5), at 0x1000c014c (dbx) lwp l@5 t@5 (l@5) stopped in __pollsys at 0x7fdd05cce13fc 0x0007fdd05cce13fc: __pollsys+0x0008: blu __cerror ! 0x7fdd05cbdce80 (dbx) where =>[1] __pollsys(0x1, 0x2, 0x0, 0x0, 0x0, 0x0), at 0x7fdd05cce13fc [2] _pollsys(0x7fdd055fff340, 0x2, 0x0, 0x0, 0x0, 0x10), at 0x7fdd05cccd6a8 [3] pselect(0x14, 0x7fdd055fffcf0, 0x7fdd055fff340, 0x7fdd05ce24c78, 0x0, 0x0), at 0x7fdd05cc2cb2c [4] select(0x14, 0x7fdd055fffcf0, 0x0, 0x0, 0x0, 0x5), at 0x7fdd05cc2ced0 [5] slapd_daemon_task(0x61bf4e9890, 0x0, 0x100382000, 0x3, 0x100401d18, 0x5), at 0x1000c014c (dbx) -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9222] New: Fix presence list to use a btree instead of an AVL tree
by openldap-its＠openldap.org 21 Jan '21

21 Jan '21

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 7

[Issue 6036] Crash: UUIDNormalize doesn't clear output on error
by openldap-its＠openldap.org 05 Dec '20

05 Dec '20

https://bugs.openldap.org/show_bug.cgi?id=6036 --- Comment #5 from amez365 <fieldengineer59(a)yahoo.com> --- Infrastructure Engineer https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer Infrastructure Engineer's roles include being responsible for designing, building, implementing and maintaining the IT infrastructure using the latest technology. An IT infrastructure engineer ensures that all IT systems that support businesses of any size operate efficiently. https://www.fieldengineer.com/skills/what-is-an-infrastructure-engineer -- You are receiving this mail because: You are on the CC list for the issue.

4 3

[Issue 9354] New: Tool for monitoring slapd status
by openldap-its＠openldap.org 02 Nov '20

02 Nov '20

https://bugs.openldap.org/show_bug.cgi?id=9354 Issue ID: 9354 Summary: Tool for monitoring slapd status Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- Something we've seen in various scripts many times - this tool continuously reports operation counts from cn=Monitor and tracks contextCSN from a specified baseDN, polling at the specified interval (default 10 seconds). It tracks when contextCSN changes start and stop, and for a set of multiprovider servers, reports the lag between consumers and providers. Sample output of a screen: 2020-09-21 06:25:36 ldap://tx01 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 95 108 617710 0 0 0 600000 0 0 9 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 idle contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:03:11 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:54 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:12:24, sync'd, max delta 00:02:19 ldap://tx02 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 105 120 2217678 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:03:09 contextCSN: 20200921004548.656746Z#000000#002#000000 idle contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:52 contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:11:33, sync'd, max delta 00:02:17 ldap://uk03 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 1407 107 675570 0 3677 0 601135 14 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:11 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:02:14 contextCSN: 20200921004446.224575Z#000000#003#000000 idle contextCSN: 20200921004331.841460Z#000000#004#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:05:56, sync'd, max delta 00:01:33 ldap://uk04 Entries Bind Unbind Search Compare Modify ModDN Add Delete Abandon Extended Num 1601143 98 116 2217670 0 0 0 400000 200000 0 3 Num/s 0.00 0.00 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00 contextCSN: 20200921004518.559704Z#000000#001#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:13 contextCSN: 20200921004548.656746Z#000000#002#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:17 contextCSN: 20200921004446.224575Z#000000#003#000000 actv@2020-09-21 00:58:57, idle@2020-09-21 01:02:11, sync'd, max delta 00:01:01 contextCSN: 20200921004331.841460Z#000000#004#000000 idle -- You are receiving this mail because: You are on the CC list for the issue.

1 4

← Newer
1
2
3
4
5
6
7
8
9
...
31
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2020