openldap-bugs September 2020

openldap-bugs@openldap.org

4 participants
300 discussions

[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9197 Bug ID: 9197 Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a customer: In order to communicate via the LB managed writable ldap, we have to ensure that an idle connection is periodically refreshed. If we do not, the LB will silently drop the connection after 5 minutes. Therefore to combat that I set an olcIdleTimeout on the writable server so that the chain cached connections will be removed before the LB timeout hits. However the slapo-ldap client goes into CLOSE_WAIT state, which causes subsequent ldapmodify updates being brokered by the read only instance to fail with err=80. There appear to be a few bugs filed on this in the past against slapd-ldap, but it's not clear if we may be hitting the same issue, or if this is a new one. I've also connected the read only instances directly to the writable ldap instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT issue is caused by the LB These were the other threads I found as I started looking for this problem, these are using the ldap-proxy though I think: https://www.openldap.org/lists/openldap-technical/201301/msg00323.html http://www.openldap.org/lists/openldap-software/201004/msg00060.html https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html The LB we have seems to be set to forget connections that last over 5 min per the setting, so the 240:10:30 seemed like it should have worked and I just thought it wasn't working because in the man page the text "Only some systems support the customization of these values" is present. however after setting keepalive to 60:10:30 did I maintain a stable connection, so there may be other network settings at play I'm not aware of. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Issue 9292] New: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9292 Issue ID: 9292 Summary: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: sshanks(a)kx.com Target Milestone: --- Ref: https://git.openldap.org/openldap/openldap/-/blob/master/doc/man/man3/ldap_… https://www.openldap.org/software/man.cgi?query=ldap_get_option&sektion=3&a… See details of LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT. Both state "the caller has to free *outvalue" This can be interpreted as the called must call free on outvalue. This can cause a random crash when 'free' used (build on Linux ran ok, Windows crashed immediately) Would be better is it stated that the caller must use 'ldap_memfree', in the same way as other options state use must use 'ldap_memfree'. FYI: within the code, get_option for these params calls ldap_int_timeval_dup which calls LDAP_MALLOC -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9238] New: access control documentation is confusing
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9238 Bug ID: 9238 Summary: access control documentation is confusing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 716 --> https://bugs.openldap.org/attachment.cgi?id=716&action=edit git format-patch output slapd.access says "Access control checking stops at the first match of the <what> and <who> clause, unless otherwise dictated by the <control> clause." But this, by itself, is wrong. You have to read the next sentence, which says there's an implicit "by * none stop", meaning that the default is to stop when only <what> matches. Patch attached. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

[Bug 9246] New: Improve authzFrom/authzTo docs
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9246 Bug ID: 9246 Summary: Improve authzFrom/authzTo docs Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 724 --> https://bugs.openldap.org/attachment.cgi?id=724&action=edit Patch The defaults for group/objectclass/attributetype were not documented. Improve the section overall. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[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

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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2020