https://bugs.openldap.org/show_bug.cgi?id=10198
Issue ID: 10198
Summary: Crash in mdb_strerr on Windows
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: b.koch(a)beckhoff.com
Target Milestone: ---
The call to FormatMessageA in mdb_strerr crashes on Windows 10 for error code
112 (disk full).
Its "Arguments" parameter is an invalid pointer. The documentation says that
the parameter should be ignored because of FORMAT_MESSAGE_IGNORE_INSERTS but my
copy of Windows disagrees. Documentation for FormatMessageA:
https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-form…
The error is (with addresses replaced by <...>):
Exception thrown at <RtlFormatMessageEx> (ntdll.dll) in
ConsoleApplication1.exe: 0xC0000005: Access violation reading location
<buf+8*1024>.
Trivial fix: Change the last parameter to NULL (in this call:
https://github.com/LMDB/lmdb/blob/8645e92b937794c06f0c66dfae64e425a085b6cd/…)
Bug 8361 is raising some additional issues in this code and it implies that the
va_list is somehow related to the padding hack (but I don't understand how that
is, to be honest), so I'm not sure whether the trivial fix would be fine.
Here is some code to reproduce the crash outside of liblmdb (tested with Visual
Studio 2022, x86 and x64, C++ console project):
#include <iostream>
#include <windows.h>
int main()
{
std::cout << "Hello World!\n";
char buf[1024];
FormatMessageA(FORMAT_MESSAGE_FROM_SYSTEM |
FORMAT_MESSAGE_IGNORE_INSERTS,
NULL, 112, 0, buf, sizeof(buf), (va_list*)buf + 1024);
char* msg = buf;
std::cout << msg;
}
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10084
Issue ID: 10084
Summary: Move away from DIGEST-MD5 as a default in the test
suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
cyrus-sasl seem on the verge or removing the DIGEST-MD5 mechanism from 2.2
onwards. As such we should update our defaults in a couple of our test scripts
for master/2.7 at least. Are SCRAM mechanisms the go-to these days?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10210
Issue ID: 10210
Summary: ldapurl manpage references options that no longer
exist
Product: OpenLDAP
Version: 2.6.7
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: ---
-h ldaphost
Set the host.
-p ldapport
Set the TCP port.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10195
Issue ID: 10195
Summary: permissive modify control without value
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: lesignor(a)cirad.fr
Target Milestone: ---
Hello,
A windows ldap client (dotnet) format the request with oid permissive modify
control like this :
00d0 30 84 00 00 00 1e 04 17 ........0.......
00e0 31 2e 32 2e 38 34 30 2e 31 31 33 35 35 36 2e 31 1.2.840.113556.1
00f0 2e 34 2e 31 34 31 33 01 01 ff 04 00 .4.1413.....
The last 2 bytes 04 00 seems to indicate no value (length of value = 0 ?).
With openldap 2.4.x this request was accepted.
With openldap 2.5.x or openldap 2.6.x, this request is rejected for invalid
protocol with error message : permissiveModify control value not absent
With ldapmodify from openldap, the same request is formatted without the last 2
bytes and is accepted.
Could it be possible to accept request with control without value formatted
with 04 00 to indicate no value ?
It will help to migrate from openldap 2.4.x to 2.5.x or 2.6.x
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8613
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10167
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10155
Issue ID: 10155
Summary: Invalid [aka FUZZ] -F and -T options can core dump
ldapsearch
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: doug.leavitt(a)oracle.com
Target Milestone: ---
A customer reported core dumps in ldapsearch which has been tracked
to the the improper use of the -F and -T options.
The customer confirmed removing the invalid -F and -T options
from their script eliminated the core dumps.
The CLI arguments of the failing ldapsearch look like:
ldapsearch <good CLI args> -F , -T u <good filter and attr args>
The good CLI args include proper uses of -H... -x -D ... -w ... -b ... -s ...
The good filter and attrs are also valid CLI inputs.
The "bad" args are <sp>-F<sp><COMMA><sp>-T<sp>-u<sp>
The -u is also valid but it is consumed as a directory name of -T
From man page and code review the the -F argument is supposed to be
a valid URL. and the -T argument is supposed to be a valid directory
The core file output indicates that main calls free
after the search takes place. The location is believed to be
here:
1658 if ( urlpre != NULL ) {
1659 if ( def_urlpre != urlpre )
1660 free( def_urlpre ); <---------
1661 free( urlpre );
1662 }
...
1672 tool_exit( ld, rc );
...
This is the first example of the use of -F we have seen
so it is unclear how this should be fixed.
But code review of ldapsearch.c and common.c exposed a few
weaknesses that could help in addressing the issue.
Observed weaknesses:
The getopt processing code for -T does not check that the arg is
actually a directory and fail/error when bad input is provided.
Perhaps at least an access(2) check should be performed?
It is unclear if -F should only accept file:// URLs. The existing code
does not sufficiently check any URL format instead it processes the
argument by looking for the first '/' [no error checking] and determine
the remainder to be a tmpdir location similar to the -T argument.
So, Fuzz input of <COMMA> seems to eventually lead to the core files.
It is unclear if -F and -T should be mutually exclusive or not.
It seems like the fix to this issue is to add better error
checking and to fail on FUZZ inputs. I defer a solution
to upstream as it probably requires project direction I lack.
--
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=10020
Issue ID: 10020
Summary: dynlist's @groupOfUniqueNames is considered only for
the first configuration line
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: msl(a)touk.pl
Target Milestone: ---
If we consider the following configuration of dynlist:
{0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames
{1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames
The {0} entry will correctly populate the memberOf relatively to static group
membership.
The {1} entry will produce dgMemberOf with dynamic group membership correctly
(based on memberURL query) but it will not populate static entries IF {0} entry
in configuration is present. IF I remove {0} from the dynlist configuration -
or - remove @groupOfUniqueNames part from this configuration line, then both
dynamic and static entries will be populated correctly for {1}.
So the effects are as follows on some user entry:
if both {0} and {1} are present - {1} produced only dynamic groups:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} -
{1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
If only {1} is present - {1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
For completness - if only {0} is present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
I would expect this behavior to be correct for the first case - {0} and {1}.
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.