https://bugs.openldap.org/show_bug.cgi?id=10205
Issue ID: 10205
Summary: SSL handshake blocks forever in async mode if server
unaccessible
Product: OpenLDAP
Version: 2.5.17
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: regtube(a)hotmail.com
Target Milestone: ---
When ldaps:// scheme is used to connect to currently unaccessible server with
LDAP_OPT_CONNECT_ASYNC and LDAP_OPT_NETWORK_TIMEOUT options set, it blocks
forever on SSL_connect.
Here is a trace:
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP winserv.test.net:636
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 192.168.56.2:636
ldap_pvt_connect: fd: 3 tm: 30 async: -1
ldap_ndelay_on: 3
attempting to connect:
connect errno: 115
ldap_int_poll: fd: 3 tm: 0
ldap_err2string
[2024-04-25 15:41:27.112] [error] [:1] bind(): Connecting (X)
[2024-04-25 15:41:27.112] [error] [:1] err: -18
ldap_sasl_bind
ldap_send_initial_request
ldap_int_poll: fd: 3 tm: 0
ldap_is_sock_ready: 3
ldap_ndelay_off: 3
TLS trace: SSL_connect:before SSL initialization
TLS trace: SSL_connect:SSLv3/TLS write client hello
Looks like it happens because non-blocking mode is cleared from the socket
(ldap_ndelay_off) after the first poll for write, and non-blocking mode is
never restored before attempt to do tls connect, because of the check that
assumes that non-blocking mode has already been set for async mode:
if ( !async ) {
/* if async, this has already been set */
ber_sockbuf_ctrl( sb, LBER_SB_OPT_SET_NONBLOCK, (void*)1 );
}
while in fact it was cleared.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10234
Issue ID: 10234
Summary: syncrepl does not reset the retrynum
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hamano(a)osstech.co.jp
Target Milestone: ---
```
syncrepl
retry="5 10 30 +"
```
When replication fails with the above settings, syncrepl retries "10 times at 5
second intervals". Then, the retry count should be reset on the next
replication failure.
In actual, it does not reset. The behavior is as follows:
```
(first time replication failure)
do_syncrepl: rid=001 rc -1 retrying (9 retries left)
do_syncrepl: rid=001 rc -1 retrying (8 retries left)
(resume replication)
(second time replication failure)
do_syncrepl: rid=001 rc -1 retrying (7 retries left)
do_syncrepl: rid=001 rc -1 retrying (6 retries left)
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10229
Issue ID: 10229
Summary: ldap_result, when invoked with MSG_RECEIVED and a
timeout value set to 0 (polling), does not return all
available messages until it is called again
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The issue is noticeable when ldap_result is used by the proxy back-ends. It has
not affected back-meta behavior, because when a first call is unsuccessful, it
retries with a small timeout. back-asyncmeta will also usually call it twice on
the same connection from different threads, although this is not a desired
behavior.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9920
Issue ID: 9920
Summary: MDB_PAGE_FULL with master3 (encryption) because there
is no room for the authentication data (MAC)
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: info(a)parlepeuple.fr
Target Milestone: ---
Created attachment 915
--> https://bugs.openldap.org/attachment.cgi?id=915&action=edit
proposed patch
Hello,
on master3, using the encryption at rest feature,
I am testing as follow:
- on a new named database, i set the encryption function with
mdb_env_set_encrypt(env, encfunc, &enckey, 32)
- note that I chose to have a size parameter (The size of authentication data
in bytes, if any. Set this to zero for unauthenticated encryption mechanisms.)
of 32 bytes.
- I add 2 entries on the DB, trying to saturate the first page. I chose to add
a key of 33 Bytes and a value of 1977 Bytes, so the size of each node is 2010
Bytes (obviously the 2 keys are different).
- This passes and the DB has just one leaf_pages, no overflow_pages, no
branch_pages, an a depth of 1.
- If I add one byte to the values I insert (starting again from a blank DB),
then , instead of seeing 2 overflow_pages, I get an error : MDB_PAGE_FULL.
- this clearly should not have happened.
- Here is some tracing :
add to leaf page 2 index 0, data size 48 key size 7 [74657374646200]
add to leaf page 3 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to branch page 5 index 0, data size 0 key size 0 [null]
add to branch page 5 index 1, data size 0 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 0, data size 1978 key size 33
[000000000000000000000000000000000000000000000000000000000000000000]
add to leaf page 4 index 1, data size 1978 key size 33
[020202020202020202020202020202020202020202020202020202020202020202]
not enough room in page 4, got 1 ptrs
upper-lower = 2020 - 2 = 2016
node size = 2020
Looking at the code, I understand that there is a problem at line 9005 :
} else if (node_size + data->mv_size > mc->mc_txn->mt_env->me_nodemax) {
where me_nodemax is incorrect, as it is not taking into account that some bytes
will be needed for the MAC authentication code, which size is in
env->me_esumsize.
me_nodemax is calculated at line 5349:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ ) / MDB_MINKEYS) & -2)
- sizeof(indx_t);
So I substract me_esumsize with a "- env->me_esumsize" here:
env->me_nodemax = (((env->me_psize - PAGEHDRSZ - env->me_esumsize) /
MDB_MINKEYS) & -2)
- sizeof(indx_t);
I also substract it from me_maxfree_1pg in the line above, and in pmax in line
10435.
I do not know if my patch is correct, but it solves the issue.
Maybe there are other places in the code where the me_esumsize should be
substracted from the available size. By example, when calculating the number of
overflow pages in OVPAGES, it does not take into account me_esumsize, but I
think it is ok, because there is only one MAC for the entire set of OV pages,
and there is room for it in the first OV page.
See the attached proposed patch.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10217
Issue ID: 10217
Summary: autoca should support more key types
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Currently autoca only creates certificates using RSA keypairs. It should at
least have an option to use Elliptic Curve keypairs. It probably also needs
options to specify other signature algorithms other than the default of SHA256.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9813
Issue ID: 9813
Summary: Incompatibility between remoteauth and ppolicy
overlays
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: thierry.pubellier(a)paris.fr
Target Milestone: ---
Hi,
We are planning to use OpenLDAP as a proxy for some users in our Active
Directory servers, using remoteauth overlay.
We want this OpenLDAP instance to also implement an account lockout policy,
preventing the lockout on our internal Active Directory servers.
But there seems to be an incompatibility between remoteauth and ppolicy
overlays : remoteauth won't remote authenticate a user if local userPassword
attribute exists, while ppolicy overlay needs this attribute.
Could there be a configuration parameter in ppolicy to allow lockout
checks/modifications (which seemed to be the default behavior of OpenLDAP
before ITS#7089) ?
I can provide a patch if allowed.
Thanks by advance,
Best regards,
Thierry
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9652
Issue ID: 9652
Summary: Add "tee" capability to load balancer
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: mhardin(a)symas.com
Target Milestone: ---
This is a request for an enhancement that would add a "tee" or "fan-out"
capability to load balancer, where received operations are sent to two or more
destinations simultaneously.
The primary goal or the enhancement is to make it possible to keep multiple
independent and likely dissimilar directory systems in lock-step with each
other over hours, days, or possibly even weeks.
The enhancement would not necessarily need to include a mechanism for
converging the target systems should they become out of sync.
This is not intended to be a replication solution, rather it is viewed more as
a "copy" solution intended to be used for specific short-term tasks that need
multiple directory systems to be exactly synchronized but where replication is
not desirable or even possible.
At least two uses come to mind:
1. Test harnesses, evaluating side-by-side operation of separate directory
systems over time
2. Directory system transition validation harnesses
3. (maybe) Part of a test harness to record or replay LDAP workloads
* Other uses?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9393
Issue ID: 9393
Summary: Provider a LDAP filter validation function
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: best(a)univention.de
Target Milestone: ---
In many situations I need to validate if a user submitted LDAP filter has valid
syntax.
It seems there is no official function to check this.
Could you provide one?
libraries/libldap/filter.c: ldap_pvt_put_filter() can be used as a basis.
--
My current workaround is using a unconnected ldap connection and do a search
with that filter. This yields a FILTER_ERROR (invalid filter) or a SERVER_DOWN
error (invalid filter).
See also:
https://github.com/python-ldap/python-ldap/pull/272
--
You are receiving this mail because:
You are on the CC list for the issue.