https://bugs.openldap.org/show_bug.cgi?id=9886
Issue ID: 9886
Summary: At "sync" logging, nothing shows how long a write op
took on consumers
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If sync logging is enabled on a consumer, there's no etime logged which means
it is not possible to see how long a write op took on that consumer. This can
be useful information to see how the node is performing, particularly if it is
a read only node where there will be no general MOD timing logged.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9952
Issue ID: 9952
Summary: Crash on exit with OpenSSL 3
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: artur.zaprzala(a)gmail.com
Target Milestone: ---
A program using libldap will crash on exit after using SSL connection.
How to reproduce on CentOS 9:
Uncomment the following lines in /etc/pki/tls/openssl.cnf:
[provider_sect]
legacy = legacy_sect
[legacy_sect]
activate = 1
Run the command (you must enter a valid LDAP server address):
python3 -c "import ldap; ldap.initialize('ldaps://<LDAP SERVER
ADDRESS>').whoami_s()"
Another example (no server required):
python3 -c "import ctypes;
ctypes.CDLL('libldap.so.2').ldap_pvt_tls_init_def_ctx(0)"
Results:
Segmentation fault (core dumped)
Backtrace from gdb:
Program received signal SIGSEGV, Segmentation fault.
0 ___pthread_rwlock_rdlock (rwlock=0x0) at pthread_rwlock_rdlock.c:27
1 0x00007ffff7c92f3d in CRYPTO_THREAD_read_lock (lock=<optimized out>) at
crypto/threads_pthread.c:85
2 0x00007ffff7c8b126 in ossl_lib_ctx_get_data (ctx=0x7ffff7eff540
<default_context_int.lto_priv>, index=1, meth=0x7ffff7eb8a00
<provider_store_method.lto_priv>) at crypto/context.c:398
3 0x00007ffff7c98bea in get_provider_store (libctx=<optimized out>) at
crypto/provider_core.c:334
4 ossl_provider_deregister_child_cb (handle=0x5555555ed620) at
crypto/provider_core.c:1752
5 0x00007ffff7c8bf2f in ossl_provider_deinit_child (ctx=0x5555555d2650) at
crypto/provider_child.c:279
6 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:283
7 OSSL_LIB_CTX_free (ctx=0x5555555d2650) at crypto/context.c:276
8 0x00007ffff7634af6 in legacy_teardown (provctx=0x5555555ee9f0) at
providers/legacyprov.c:168
9 0x00007ffff7c9901b in ossl_provider_teardown (prov=0x5555555ed620) at
crypto/provider_core.c:1477
10 ossl_provider_free (prov=0x5555555ed620) at crypto/provider_core.c:683
11 0x00007ffff7c63956 in ossl_provider_free (prov=<optimized out>) at
crypto/provider_core.c:668
12 evp_cipher_free_int (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1632
13 EVP_CIPHER_free (cipher=0x555555916c10) at crypto/evp/evp_enc.c:1647
14 0x00007ffff7a6bc1d in ssl_evp_cipher_free (cipher=0x555555916c10) at
ssl/ssl_lib.c:5925
15 ssl_evp_cipher_free (cipher=0x555555916c10) at ssl/ssl_lib.c:5915
16 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3455
17 SSL_CTX_free (a=0x555555ec1020) at ssl/ssl_lib.c:3392
18 0x00007fffe95edb89 in ldap_int_tls_destroy (lo=0x7fffe9616000
<ldap_int_global_options>) at
/usr/src/debug/openldap-2.6.2-1.el9_0.x86_64/openldap-2.6.2/libraries/libldap/tls2.c:104
19 0x00007ffff7fd100b in _dl_fini () at dl-fini.c:138
20 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:113
21 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143
22 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20
<main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2b8) at
../sysdeps/nptl/libc_start_call_main.h:74
23 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>,
argc=4, argv=0x7fffffffe2b8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe2a8) at ../csu/libc-start.c:409
24 0x000055555556b575 in _start ()
The problem is that ldap_int_tls_destroy() is called after the clean up of
libssl.
On program exit, at first default_context_int is cleaned up (OPENSSL_cleanup()
was registered with atexit()):
0 ossl_lib_ctx_default_deinit () at crypto/context.c:196
1 OPENSSL_cleanup () at crypto/init.c:424
2 OPENSSL_cleanup () at crypto/init.c:338
3 0x00007ffff7873475 in __run_exit_handlers (status=0, listp=0x7ffff7a11658
<__exit_funcs>, run_list_atexit=run_list_atexit@entry=true,
run_dtors=run_dtors@entry=true) at exit.c:113
4 0x00007ffff78735f0 in __GI_exit (status=<optimized out>) at exit.c:143
5 0x00007ffff785be57 in __libc_start_call_main (main=main@entry=0x55555556aa20
<main>, argc=argc@entry=4, argv=argv@entry=0x7fffffffe2c8) at
../sysdeps/nptl/libc_start_call_main.h:74
6 0x00007ffff785befc in __libc_start_main_impl (main=0x55555556aa20 <main>,
argc=4, argv=0x7fffffffe2c8, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fffffffe2b8) at ../csu/libc-start.c:409
7 0x000055555556b575 in _start ()
Then ossl_lib_ctx_get_data() tries to use default_context_int.lock, which is
NULL. ldap_int_tls_destroy() is called by ldap_int_destroy_global_options(),
registered by "__attribute__ ((destructor))".
It seems that shared library destructors are always called before functions
registered with atexit().
A solution may be to modify libraries/libldap/init.c to use atexit() instead of
"__attribute__ ((destructor))". atexit() manual page says: "Since glibc 2.2.3,
atexit() can be used within a shared library to establish functions that are
called when the shared library is unloaded.".
Functions registered with atexit() are called in the reverse order of their
registration, so libssl must by initialized before libldap. If the order is
wrong, libldap should detect it somehow and exit with abort().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9827
Issue ID: 9827
Summary: Feature request for module argon2.so to support
Argon2i, Argon2d, Argon2id
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: juergen.sprenger(a)swisscom.com
Target Milestone: ---
Hi,
This is a feature request.
I would like to be able to chooses between Argon2i, Argon2d and Argon2id in
slappasswd like in argon2 command:
# argon2
Usage: argon2 [-h] salt [-i|-d|-id] [-t iterations] [-m log2(memory in KiB) |
-k memory in KiB] [-p parallelism] [-l hash length] [-e|-r] [-v (10|13)]
Password is read from stdin
Parameters:
salt The salt to use, at least 8 characters
-i Use Argon2i (this is the default)
-d Use Argon2d instead of Argon2i
-id Use Argon2id instead of Argon2i
-t N Sets the number of iterations to N (default = 3)
-m N Sets the memory usage of 2^N KiB (default 12)
-k N Sets the memory usage of N KiB (default 4096)
-p N Sets parallelism to N threads (default 1)
-l N Sets hash output length to N bytes (default 32)
-e Output only encoded hash
-r Output only the raw bytes of the hash
-v (10|13) Argon2 version (defaults to the most recent version,
currently 13)
-h Print argon2 usage
Example:
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so i" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so d" -s secret
/usr/local/etc/openldap # /usr/sbin/slappasswd -h "{ARGON2}" -o
module-load="argon2.so id" -s secret
Best regards
Juergen Sprenger
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9934
Issue ID: 9934
Summary: slapd-config(5) should document how to store
certificates for slapd usage
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Commit 7b41feed83b expanded the ability of cn=config to save the certificates
used for TLS by slapd directly in the config database. However the
documentation for the new parameters was never added to the slapd-config(5) man
page.
olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey
--
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.
https://bugs.openldap.org/show_bug.cgi?id=9914
Issue ID: 9914
Summary: Add OS pagesize to the back-mdb monitor information
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The pagesize that back-mdb is using for pages should be exposed via the
cn=monitor backend, as a remote client doing a query will not have that
information available to it.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9211
Bug ID: 9211
Summary: Relax control is not consistently access-restricted
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
The following operations can be performed by anyone having 'write' access (not
even 'manage') using the Relax control:
- modifying/replacing structural objectClass
- adding/modifying OBSOLETE attributes
Some operations are correctly restricted:
- adding/modifying NO-USER-MODIFICATION attributes marked as manageable
(Modification of non-conformant objects doesn't appear to be implemented at
all.)
In the absence of ACLs for controls, I'm of the opinion that all use of the
Relax control should require manage access. The Relax draft clearly and
repeatedly discusses its use cases in terms of directory _administrators_
temporarily relaxing constraints in order to accomplish a specific task.
--
You are receiving this mail because:
You are on the CC list for the bug.
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=9596
Issue ID: 9596
Summary: Python test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The bash test suite is extremely limited, hard to write for and slow. We can't
lose it as it is also portable, but something should be introduced for
developers/CI on more modern systems and increase coverage.
A Python 3 seed for one is in development in MR!347.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9786
Issue ID: 9786
Summary: liblber: missing export of ber_pvt_wsa_err2string
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: tobias.junghans(a)veyon.io
Target Milestone: ---
When building (cross-compiling) OpenLDAP via GCC/mingw-w64, an undefined
reference to ber_pvt_wsa_err2string() is reported when libldap.dll is linked.
This can be fixed easily by adding ber_pvt_wsa_err2string() to
libraries/liblber/lber.map
--
You are receiving this mail because:
You are on the CC list for the issue.