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.
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.
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.
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.
https://bugs.openldap.org/show_bug.cgi?id=9426
Issue ID: 9426
Summary: Paged results return duplicates
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When performing a query that matches 744 entries, the number of returned
entries varies depending on the page size requested.
For a page size of 300, it returns 767 entries
For a page size of 500, it returns 759 entries
Running the results for sort -u correctly shows 744 unique entries. So
anywhere from 15 to 23 duplicates are returned in the above case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9442
Issue ID: 9442
Summary: slapo-constraint negated regex
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: david(a)barchie.si
Target Milestone: ---
slapo-constraint doesn't conveniently allow setting a constraint with a negated
regex.
Taking grep as an example (i.e. --invert-match), I propose adding a constraint
type that allows using a regex in a negated way. When a match is found a
constraint error is raised.
The configuration entry would look like the following:
> constraint_attribute mail negregex ^.*(a)somedomain\.com$
This feature request was started on the openldap-devel mailing list,
https://lists.openldap.org/hyperkitty/list/openldap-devel@openldap.org/thre…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9440
Issue ID: 9440
Summary: null ptr dereference in error message for invalid
generic control value
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Created attachment 787
--> https://bugs.openldap.org/attachment.cgi?id=787&action=edit
fix
> $ ldapmodify -e 1.2.3.4=xxx
> Unable to parse value of general control (null)
Trailing `(null)' is not what expected. Fix attached. After fix:
> Unable to parse value `xxx' of general control `1.2.3.4'
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9381
Issue ID: 9381
Summary: librewrite warnings for unused variables
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
There are some unused variables in librewrite that need fixing, and one case
where an rc is set but never returned which also needs addressing.
--
You are receiving this mail because:
You are on the CC list for the issue.