openldap-bugs November 2020

openldap-bugs@openldap.org

1 participants
96 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 9400] New: Proxy bind retry fails after remote server disconnects
by openldap-its＠openldap.org 22 Feb '21

22 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9400 Issue ID: 9400 Summary: Proxy bind retry fails after remote server disconnects Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tero.saarni(a)est.tech Target Milestone: --- Problem description ------------------- I'm using slapd-ldap to proxy for a remote LDAP server. LDAP backend is configured to: - allow user binds that are passed directly to the remote LDAP server - allow local user binds that are mapped to remote bind using idassert-bind The problem happens when remote LDAP server abruptly disconnects the (idle) LDAP connection. For example, next search operation will fail with error: Server is unavailable (52) Additional information: misconfigured URI? The operation will succeed when repeating it for second time. Reproducing the problem ----------------------- I created a test case that reproduces the problem - https://git.openldap.org/tsaarni/openldap/-/compare/master...ldap-back-retr… Preliminary troubleshooting --------------------------- While troubleshooting this I observed following: (A) The problem is related to retry after remote server abruptly dropped the LDAP connection. Call chain ldap_back_retry() -> ldap_back_dobind_int() -> ldap_back_is_proxy_authz() ends up in this branch: if ( !( li->li_idassert_flags & LDAP_BACK_AUTH_OVERRIDE )) { if ( op->o_tag == LDAP_REQ_BIND ) { if ( !BER_BVISEMPTY( &ndn )) { dobind = 0; goto done; } where "dobind = 0" causes "binddn" and "bindcred" return variables NOT to be filled. Then in ldap_back_dobind_int() we fall into this branch: if ( LDAP_BACK_CONN_ISIDASSERT( lc ) ) { if ( BER_BVISEMPTY( &binddn ) && BER_BVISEMPTY( &bindcred ) ) { /* if we got here, it shouldn't return result */ rc = ldap_back_is_proxy_authz( op, rs, LDAP_BACK_DONTSEND, &binddn, &bindcred ); if ( rc != 1 ) { Debug( LDAP_DEBUG_ANY, "Error: ldap_back_is_proxy_authz " "returned %d, misconfigured URI?\n", rc ); rs->sr_err = LDAP_OTHER; rs->sr_text = "misconfigured URI?"; LDAP_BACK_CONN_ISBOUND_CLEAR( lc ); if ( sendok & LDAP_BACK_SENDERR ) { send_ldap_result( op, rs ); } goto done; } } (B) The problem does NOT occur if configuring separate instances of back-ldap: - one backend for users: BIND is done with users own credentials - no idassert - second backend for local admin: local admin BIND is overwritten with idassert-bind Possibly the same problem have been discussed also earlier, for example - https://www.openldap.org/lists/openldap-technical/201307/msg00070.html - https://www.openldap.com/lists/openldap-bugs/201511/msg00041.html - https://www.openldap.org/lists/openldap-bugs/201905/msg00001.html -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[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 9386] New: New draft 10 ppolicy segfaults if default policy entry doesn't exist
by openldap-its＠openldap.org 08 Feb '21

08 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9386 Issue ID: 9386 Summary: New draft 10 ppolicy segfaults if default policy entry doesn't exist 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: --- Nov 6 13:25:15 anvil4 slapd[3342]: conn=7945 op=0 SRCH attr=monitorCounter monitorOpInitiated monitorOpCompleted monitoredInfo Nov 6 13:25:15 anvil4 slapd[3342]: conn=7945 op=0 SEARCH RESULT tag=101 err=0 qtime=0.000042 etime=0.004444 nentries=55 text= Nov 6 13:25:15 anvil4 slapd[3342]: conn=7945 fd=17 closed (connection lost) Nov 6 13:25:24 anvil4 slapd[3342]: conn=7944 op=1 MOD dn="cn=people memberOf,ou=bind permissions,dc=xxx,dc=yyy,dc=edu" Nov 6 13:25:24 anvil4 slapd[3342]: conn=7944 op=1 MOD attr=member Nov 6 13:25:24 anvil4 slapd[3342]: ppolicy_get: policy subentry cn=passworddefault,ou=policies,dc=xxx,dc=yyy,dc=edu missing or invalid Nov 6 13:25:24 anvil4 kernel: [353965.330607] show_signal_msg: 5 callbacks suppressed Nov 6 13:25:24 anvil4 kernel: [353965.330633] slapd[3349]: segfault at 30 ip 00007f953e581b49 sp 00007f8dbcf54240 error 6 in ppolicy10-2.4.so.2.11.1[7f953e578000+f000] -- You are receiving this mail because: You are on the CC list for the issue.

1 5

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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2020