[Issue 9400] New: Proxy bind retry fails after remote server disconnects
by openldap-its＠openldap.org
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-re...
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.
2 years, 3 months
[Issue 9332] New: Compilation of 2.4.52 fails: "init.c", line 45: too many initializers for scalar
by openldap-its＠openldap.org
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.
2 years, 3 months
[Issue 9426] New: Paged results return duplicates
by openldap-its＠openldap.org
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.
2 years, 3 months
[Issue 9442] New: slapo-constraint negated regex
by openldap-its＠openldap.org
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/th...
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 3 months
[Issue 9416] New: Malformed componentfiltermatch packets cause crashes
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9416
Issue ID: 9416
Summary: Malformed componentfiltermatch packets cause crashes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: phasip(a)gmail.com
Target Milestone: ---
Another packet for componentFilterMatch that crashes. Not done any research as
to why.
Packet:
00000000: 3082 017f 0201 0d63 8200 39df 920a 008c 0......c..9.....
00000010: 00e7 00d0 0070 0096 00a0 81f7 7145 770c .....p......qEw.
00000020: de51 85c4 fe31 d1a8 be3e 3e14 0b8c 3ba8 .Q...1...>>...;.
00000030: 00ed 533b 779f ebdd e358 7649 f274 cfd5 ..S;w....XvI.t..
00000040: a311 04de 6bf0 c937 0624 6e8c 70a9 ac92 ....k..7.$n.p...
00000050: f7b9 ecad 03c3 be19 2f8f 2daa d44b 93b6 ......../.-..K..
00000060: 0d9b b9e7 2d54 df37 dfe5 ebd2 456b 55c5 ....-T.7....EkU.
00000070: 9df2 4a9c 7f29 257f ff04 deb3 6739 3965 ..J..)%.....g99e
00000080: c00b 1280 1644 f3c0 81b5 20e9 226a 9210 .....D.... ."j..
00000090: 19aa a900 8114 636f 6d70 6f6e 656e 7446 ......componentF
000000a0: 696c 7465 724d 6174 6368 8320 6e6f 743a ilterMatch. not:
000000b0: 007f 5004 deb3 6739 3965 c00b 1280 1644 ..P...g99e.....D
000000c0: f3c0 81b5 20e9 226a 9210 19aa a900 8114 .... ."j........
000000d0: 636f 6d70 6f6e 656e 7446 696c 7465 724d componentFilterM
000000e0: 6174 6368 8320 6e6f 7420 007f 5004 deb3 atch. not ..P...
000000f0: 6739 3965 c00b 1280 1644 f3c0 81b5 20e9 g99e.....D.... .
00000100: 226a 9210 19aa a900 8114 636f 6d70 6f6e "j........compon
00000110: 656e 7446 696c 7465 724d 6174 6368 835c entFilterMatch.\
00000120: 2020 5c20 205c 2020 5c20 2044 5c20 205c \ \ \ D\ \
00000130: 2020 5c20 205c 2020 5c20 205c 2020 5c20 \ \ \ \ \
00000140: 205c 2020 5c20 205c 2020 5c5c 2020 5c20 \ \ \ \\ \
00000150: 205c 2020 5c20 205c 2020 5c20 205c 203d \ \ \ \ \ =
00000160: 5c20 202e 315c 2020 205c 2020 5c20 205c \ .1\ \ \ \
00000170: 2020 5c20 205c 2020 5c20 205c 2020 5c2e \ \ \ \ \.
00000180: 362b 7f23 34ff 8900 0005 a333 802b 7f23 6+.#4......3.+.#
00000190: 312e 332e 362e 502e df49 0a22 8980 00ff 1.3.6.P..I."....
000001a0: ffff 7780 00ff ffff ffff ffb1 0e82 0100 ..w.............
000001b0: 4212 ff B..
GDB output:
Starting program: /openldap/servers/slapd/slapd -h ldap://:1389/ -d 256
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
5fc938c6 @(#) $OpenLDAP: slapd 2.X (Dec 3 2020 19:06:47) $
@8d4e8dc0a9bb:/openldap/servers/slapd
5fc938c6 slapd starting
[New Thread 0x7fff8b2d3700 (LWP 11)]
[New Thread 0x7fff8aad2700 (LWP 12)]
5fc938d5 conn=1000 fd=11 ACCEPT from IP=127.0.0.1:50460 (IP=0.0.0.0:1389)
[New Thread 0x7fff8a2d1700 (LWP 13)]
5fc938d5 get_filter: unknown filter type=113
5fc938d5 get_filter: unknown filter type=231
--Type <RET> for more, q to quit, c to continue without paging--
Thread 4 "slapd" received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7fff8a2d1700 (LWP 13)]
0x00005555555f8309 in parse_comp_filter (op=op@entry=0x7fff80000d50,
cav=cav@entry=0x7fff8a2cf790, filt=filt@entry=0x7fff89ad2078,
text=text@entry=0x7fff8a2d0aa0) at component.c:1073
1073 tag = strip_cav_tag( cav );
Testing:
(Alternative to using docker hub: docker build -t phasip/openldap
https://github.com/Phasip/openldap-docker.git#main)
# Using privileged here for gdb access
docker pull phasip/openldap
docker run --privileged -it --net=host --entrypoint gdb phasip/openldap
/openldap/servers/slapd/slapd -ex 'set args -h ldap://:1389/ -d 256' -ex 'run'
echo -en
'\x30\x82\x01\x7f\x02\x01\x0d\x63\x82\x00\x39\xdf\x92\x0a\x00\x8c\x00\xe7\x00\xd0\x00\x70\x00\x96\x00\xa0\x81\xf7\x71\x45\x77\x0c\xde\x51\x85\xc4\xfe\x31\xd1\xa8\xbe\x3e\x3e\x14\x0b\x8c\x3b\xa8\x00\xed\x53\x3b\x77\x9f\xeb\xdd\xe3\x58\x76\x49\xf2\x74\xcf\xd5\xa3\x11\x04\xde\x6b\xf0\xc9\x37\x06\x24\x6e\x8c\x70\xa9\xac\x92\xf7\xb9\xec\xad\x03\xc3\xbe\x19\x2f\x8f\x2d\xaa\xd4\x4b\x93\xb6\x0d\x9b\xb9\xe7\x2d\x54\xdf\x37\xdf\xe5\xeb\xd2\x45\x6b\x55\xc5\x9d\xf2\x4a\x9c\x7f\x29\x25\x7f\xff\x04\xde\xb3\x67\x39\x39\x65\xc0\x0b\x12\x80\x16\x44\xf3\xc0\x81\xb5\x20\xe9\x22\x6a\x92\x10\x19\xaa\xa9\x00\x81\x14\x63\x6f\x6d\x70\x6f\x6e\x65\x6e\x74\x46\x69\x6c\x74\x65\x72\x4d\x61\x74\x63\x68\x83\x20\x6e\x6f\x74\x3a\x00\x7f\x50\x04\xde\xb3\x67\x39\x39\x65\xc0\x0b\x12\x80\x16\x44\xf3\xc0\x81\xb5\x20\xe9\x22\x6a\x92\x10\x19\xaa\xa9\x00\x81\x14\x63\x6f\x6d\x70\x6f\x6e\x65\x6e\x74\x46\x69\x6c\x74\x65\x72\x4d\x61\x74\x63\x68\x83\x20\x6e\x6f\x74\x20\x00\x7f\x50\x04\xde\xb3\x67\x39\x39\x65\xc0\x0b\x12\x80\x16\x44\xf3\xc0\x81\xb5\x20\xe9\x22\x6a\x92\x10\x19\xaa\xa9\x00\x81\x14\x63\x6f\x6d\x70\x6f\x6e\x65\x6e\x74\x46\x69\x6c\x74\x65\x72\x4d\x61\x74\x63\x68\x83\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x44\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x3d\x5c\x20\x20\x2e\x31\x5c\x20\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x20\x20\x5c\x2e\x36\x2b\x7f\x23\x34\xff\x89\x00\x00\x05\xa3\x33\x80\x2b\x7f\x23\x31\x2e\x33\x2e\x36\x2e\x50\x2e\xdf\x49\x0a\x22\x89\x80\x00\xff\xff\xff\x77\x80\x00\xff\xff\xff\xff\xff\xff\xb1\x0e\x82\x01\x00\x42\x12\xff'
| nc localhost 1389
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 3 months
[Issue 9386] New: New draft 10 ppolicy segfaults if default policy entry doesn't exist
by openldap-its＠openldap.org
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.
2 years, 3 months
[Issue 9381] New: librewrite warnings for unused variables
by openldap-its＠openldap.org
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.
2 years, 3 months
[Issue 9380] New: connection_write_resume should be type void rather than int
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9380
Issue ID: 9380
Summary: connection_write_resume should be type void rather
than int
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: ---
connection_write_resume does not return anything, but is declared to return an
int. This can cause compile failure depending on the flags used during
compilation (-Werror=return-type)
--
You are receiving this mail because:
You are on the CC list for the issue.
2 years, 3 months
[Issue 9322] New: Update admin guide to recommend OpenSSL 1.1 as a minimum release
by openldap-its＠openldap.org
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.
2 years, 3 months