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=10058
Issue ID: 10058
Summary: destroying robust mutexes leads to use of an
uninitialized mutex
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: jiri.novosad(a)gmail.com
Target Milestone: ---
Created attachment 966
--> https://bugs.openldap.org/attachment.cgi?id=966&action=edit
an example program to reproduce the bug
This is a regression introduced in
https://bugs.openldap.org/show_bug.cgi?id=9278 .
The issue is that mdb_env_setup_locks initializes the mutex only when it gets
an exclusive fcntl file lock. But there is this possible order of operations:
1. Process A opens the DB, gets an exclusive file lock, initializes the mutex,
downgrades the file lock to shared and does its thing
2. Process A closes the env: it gets an exclusive lock and destroys the mutex
3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the
shared lock
4. Process A finishes closing the env, closes the file descriptor and loses the
file lock
5. Process B gets the shared lock, does not initialize the mutex in
mdb_env_setup_locks (because it does not have the exclusive lock)
6. Process B tries to lock the mutex, but it is not initialized,
pthread_mutex_lock returns EINVAL
--
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=10047
Issue ID: 10047
Summary: slapd SEGV after slapindex -q
Product: OpenLDAP
Version: 2.6.3
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: ---
In an environment where cn=config is replicated:
a) Added an equality index for an existing attribute
b) Stopped slapd after the change to the configuration had been replicated to
the server. The indexing process that was automatically kicked off by this had
been running for ~30 minutes before I stopped slapd
c) ran: slapindex -q -F /path/to/config -b <base> <attr>
d) started slapd
e) segfault
To verify it wasn't an overall data issue, I then:
a) slapcat the database
b) moved the problem database files aside for debugging
c) reloaded the database with slapadd -q
d) everything works fine
I will attach the gdb output to this ticket momentarily
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10042
Issue ID: 10042
Summary: Crash when back-monitor search fails/is abandoned
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The fix in ITS#9832 was incomplete, some paths leading to "freeout:" can have
passed through monitor_cache_release already.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9993
Issue ID: 9993
Summary: Potential race condition in back-mdb online indexer
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the online indexer completes, it should mutex-protect its resetting of the
indexing flags.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10039
Issue ID: 10039
Summary: configure fails to detect
SSL_export_keying_material_early with LibreSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orbea(a)riseup.net
Target Milestone: ---
Created attachment 957
--> https://bugs.openldap.org/attachment.cgi?id=957&action=edit
config.log
When configuring OpenLDAP using --with-tls=openssl with LibreSSL the configure
will fail to detect SSL_export_keying_material_early since LibreSSL doesn't
support this function yet. However OpenLDAP doesn't actually use this function
so this can be easily solved by checking for SSL_library_init which is a more
standard function which both OpenSSL and LibreSSL support which OpenLDAP
actually uses in libraries/libldap/tls_o.c.
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_export_keying_material_early in -lssl... no
configure: error: Could not locate TLS/SSL package
Other than this the build succeeds correctly with at least LibreSSL 3.7.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9995
Issue ID: 9995
Summary: Potential memory leak in clients/tools/ldapdelete.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapdelete.c line 384.Calling ldap_search_ext_s()
without calling ldap_msgfree() to free the memory will cause a memory leak.
Doc says "Note that res parameter of ldap_search_ext_s() and
ldap_search_s() should be freed with ldap_msgfree() regardless of return value
of these functions." in
https://www.openldap.org/software/man.cgi?query=ldap_search_ext_s&apropos=0…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10032
Issue ID: 10032
Summary: at_add returns a free'd pointer on error
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When an invalid schema is provided (e.g. the current
./servers/slapd/schema/msuser.schema of memberof/dynlist is loaded already),
at_add() hits error handling and frees at->at_oid, but that string is being
returned in *err. A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.