https://bugs.openldap.org/show_bug.cgi?id=10219
Issue ID: 10219
Summary: Modify of olcDisabled by removing and adding a value
invokes db_open twice
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
A database is enabled by default, and therefore a missing olcDisabled attribute
is equivalent to a value of FALSE. This means that currently a modify operation
that removes a olcDisabled value will invoke the db_open handler for that
database, even if in the same modify operation a value of TRUE is added.
A modify operation like this:
dn: olcDatabase={1}asyncmeta,cn=config
changetype: modify
delete: olcDisabled
olcDisabled: FALSE
-
add: olcDisabled
olcDisabled: TRUE
-
will call both db_open and db_close. This could be potentially harmful if the
backend type allocates memory on db_open like asyncmeta, for example. It is a
rare case, but it is best to fix it just in case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10218
Issue ID: 10218
Summary: Disabling and re-enabling an asyncmeta database via
cn=config leaks memory
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
To reproduce - run OpenLDAP with valgrind, and set the olcDisabled attribute of
an asyncmeta database to TRUE, then again to FALSE. The connection structures
of the database are subsequently shown as leaked.
--
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=10147
Issue ID: 10147
Summary: Bind dn is getting malformed inside ldap_sasl_bind
function
Product: OpenLDAP
Version: 2.6.3
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: satishkumar1728(a)gmail.com
Target Milestone: ---
Hi team,
We are using open ldap version 2.6 in one of our application processes.
We are using ldap_sasl_bind function defined in open ldap api to send bind
request to ldap server.
We are passing the dn name to the above function and it is parsing the dn name
as expected.
We have added some print statements inside ldap_sasl_bind function and it is
printing the dn string that we passed to the function.
Also, ldap_sasl_bind function will accept const char pointer to dn as an
argument. So, it cannot modify the dn string inside the function.
But somehow the bind dn is getting malformed and we are getting failed bind
response from the ldap server (invalid DN).
We did some analysis using tcpdump and we found out that the dn string that we
passed to the ldap_sasl_bind function and the dn string from the tcpdump are
different.
We did some code walkthrough of ldap_sasl_bind function and it is observed that
it is doing some ber encoding of dn name inside the function.
We are suspecting that the encoding is not happening properly.
Example dn that we passed to ldap_sasl_bin function: "uid=abc, ou=users,
dc=fds, dc=mr"
Dn name that was captured in tcpdump at source: "uid=abc, o dc= dc= dc= dc=
dc=mr"
Is there any specific reason for the bind DN to get malformed like this inside
ldap_sasl_bind function.
Do you have any observations like this in any scenario. Kindly provide some
inputs to resolve this issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10175
Issue ID: 10175
Summary: Secure LDAP is not working on GCC 10.3.0
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: bluesoulprince(a)gmail.com
Target Milestone: ---
Hi Team,
We have recently migrated our C++ application which is using OpenLDAP 2.6 to
GCC version 10.3.0.
We are observing difference in LDAP behavior. The non-secure version of LDAP is
able to return the result in GCC 10.3.0, however when we switch to secure LDAP,
it is not able to return with result.
There was no compilation / build issue observed while building our application.
Our query is, does secure LDAP from OpenLDAP ver 2.6 have any compatibility
issues over GCC 10.3.0?
If there are any issues identified over this version, how to resolve those? in
which version fixes for them are available?
Thanks,
Vivek
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10140
Issue ID: 10140
Summary: Add microsecond timestamp format for local file
logging
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
Add microsecond-level timestamps to local file logging.
Format is:
"YYYY-mm-ddTHH:MM:SS.ffffffZ"
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or
interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2023 Gregory Noe
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10138
Issue ID: 10138
Summary: Allow generating multiple nested read transactions
from a write transaction
Product: LMDB
Version: 0.9.30
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hello,
I have a feature request. Would it be possible to read a database from the
point of view of a non-yet-committed write transaction?
What I want to do is to write a lot of entries into a database, use a couple of
threads to read those entries (using MDB_NOTLS) to generate a lot of new
entries (that will be written to disk and then once the generation is done,
drop the read-transaction handles and write (with MDB_APPEND) those new entries
from disk into LMDB.
This would have been possible if I had committed the first entries, but
unfortunately, it is impossible. I need to do this in the same transaction.
Have a great day,
kero
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10220
Issue ID: 10220
Summary: Feature Request: new option for append-only write
transaction
Product: LMDB
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: xhtang518(a)gmail.com
Target Milestone: ---
My project uses LMDB to store values larger than 100KB, and rarely delete
values. So I can afford wasting some space on free pages, then LMDB can reduce
4KB-write operations and improve write performance when committing write
transactions.
I suppose this feature is not hard to implement: just pretend the free-list is
empty in this transaction if the new option is present.
Is this feature reasonable?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10172
Issue ID: 10172
Summary: check for writability of directory of logfile during
startup
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Even if the logfile itself is writable, if the enclosing directory is not
writable then slapd won't be able to perform logfile rotation. Check for
this when the logfile is being configured. This will prevent starting up
with a bad config, but we still can't do anything about it if the directory's
perms are changed while slapd is already running. Logging an error message
in that situation would likely fill all disk space with that error message.
--
You are receiving this mail because:
You are on the CC list for the issue.