https://bugs.openldap.org/show_bug.cgi?id=4501
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |needs_review
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |smckinney(a)symas.com
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=4501
--- Comment #6 from Fredrik Roubert <fredrik(a)roubert.name> ---
Does anyone have any opinion about this?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10018
Issue ID: 10018
Summary: lmdb runs for two years and triggers abort error
Product: LMDB
Version: 0.9.23
Hardware: Other
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: Zhou.chang(a)h3c.com
Target Milestone: ---
We found that when the Last transaction ID exceeds the maximum value, the
database abort signal will be triggered and two errors will be reported:
Assertion 'rc == 0' failed in mdb_page_dirty()
Assertion 'mp->mp_pgno != pgno' failed in mdb_page_touch()
I would like to ask whether the current lmdb has considered this situation,
./mdb_stat -e /tmp/lmdb
Environment Info
Map address: (nil)
Map size: 10485760
Page size: 4096
Max pages: 2560
Number of pages used: 238
Last transaction ID: 4294967295
Max readers: 126
Number of readers used: 2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8447
Howard Chu <hyc(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |TEST
--- Comment #4 from Howard Chu <hyc(a)openldap.org> ---
Fixed in mdb.master c7b3cc4df6dfe8f0772fb509bdc74777667caa43
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10007
Issue ID: 10007
Summary: lmdb does not work on MSYS2/Cygwin
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: facboy(a)gmail.com
Target Milestone: ---
lmdb can be compiled if the correct flags are set on MSYS2/Cygwin, but it does
not actually work. `make test` will result in errors.
If `make CPPFLAGS="-DMDB_USE_ROBUST=0"` is used, `mtest` fails with:
> mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): Invalid argument
> Aborted (core dumped)
If `make CPPFLAGS="-DMDB_USE_POSIX_SEM=1"` is used, `mtest` fails with:
> mtest.c:50: mdb_env_open(env, "./testdb", MDB_FIXEDMAP , 0664): No such file or directory
> Aborted (core dumped)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9972
Issue ID: 9972
Summary: SSS needs READ instead of SEARCH access
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dpa-openldap(a)aegee.org
Target Milestone: ---
I have configured an OpenLDAP 2.6 server with
dn: olcDatabase=mdb,cn=config
objectClass: olcDatabaseConfig
objectClass: olcMdbConfig
olcDatabase: mdb
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * search # no problem if this is READ
olcAccess: to dn.sub="dc=aegee,dc=org"
by * read
…
dn: olcOverlay=sssvlv,olcDatabase={1}mdb,cn=config
objectClass:olcOverlayConfig
The content of the tree is available anymously by calling
ldapsearch -ZZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub .
When I modify the call to use SSS:
ldapsearch -ZxH ldap://ldap.aegee.org -b "dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
it also returns results, but ends with
```
# search result
search: 93
result: 50 Insufficient access
# numResponses: 3
# numEntries: 2
```
When I modify above:
olcAccess: to dn="cn=bodies,dc=aegee,dc=org"
by * read
then the access is sufficient.
There is no entry called "dn:cn=bodies,dc=aegee,dc=org", or rather the entry
shall not be returned on searches and `ldapsearch -ZxH ldap://ldap.aegee.org -b
"dc=aegee,dc=org" -s sub` does not return it.
These work without a problem:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one -E
sss=ou:2.5.13.15
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s one
This produces Insufficient access:
ldapsearch -ZxH ldap://ldap.aegee.org -b "cn=bodies,dc=aegee,dc=org" -s sub -E
sss=ou:2.5.13.15
That said client-side-sorting does work without a problem, but server-side
sorting requires not only SEARCH, but also READ privileges on
dn="cn=bodies,dc=aegee,dc=org".
I find this is a bug: SSS requires read-acesss to data, which is not supposed
to be returned to the client (dn:cn=bodies,dc=aegee,dc=org). For the
additional server-side sorting no additional privileges shall be required,
compared to returning the results without server-side-sorting.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10009
Issue ID: 10009
Summary: test076 execution failed
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: 1010881517(a)qq.com
Target Milestone: ---
openldap-2.6.3test case test076-authid-rewrite failed when I upgrade openssl to
openssl3.0
Does anyone have a similar problem?
>>>>> 00:27:30 Starting test076-authid-rewrite for mdb...
running defines.sh
Starting slapd on TCP/IP port 9011...
/home/abuild/rpmbuild/BUILD/openldap-2.6.3/openldap-2.6.3/tests
Using ldapsearch to check that slapd is running...
Checking whether DIGEST-MD5 is supported...
Adding schema and database...
Using ldapadd to populate the database...
Adding olcAuthzRegexp rule for static mapping...
Testing ldapwhoami as Manager...
./scripts/test076-authid-rewrite: line 177: 219330 Segmentation fault
(core dumped) $LDAPSASLWHOAMI -H $URI1 -Y $MECH -U $ID -w $PASSWD
ldapwhoami failed (139)!
>>>>> 00:27:33 Failed test076-authid-rewrite for mdb after 3 seconds
(exit 139)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10012
Issue ID: 10012
Summary: fcntl called without checking value
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: balaev(a)tarantool.org
Target Milestone: ---
Created attachment 949
--> https://bugs.openldap.org/attachment.cgi?id=949&action=edit
patch file
ldap_pvt_socket() and ldap_int_socket() calls fcntl without checking value of
file descriptor.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10008
Issue ID: 10008
Summary: Makefile does not building DLLs on Cygwin/MSYS2
Product: LMDB
Version: unspecified
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: facboy(a)gmail.com
Target Milestone: ---
Currently when building on Cygwin/MSYS2 make does not generate DLL files.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8447
--- Comment #3 from nicolas.werner(a)hotmail.de ---
I can reproduce this without using any cursors. I am using the lmdb++ header
for simplicity (https://github.com/hoytech/lmdbxx), but it also reproduces
using the plain C API. Full repro:
#include <iostream>
#include <stdlib.h>
#include "lmdb++.h"
#define PROJECT_NAME "mdb-dup-bug"
static int compare_state_key(const MDB_val *a, const MDB_val *b)
{
auto get_skey = [](const MDB_val *v) {
std::string_view data(static_cast<const char
*>(v->mv_data), v->mv_size);
return data.substr(0, data.find(','));
};
return get_skey(a).compare(get_skey(b));
}
int main(int argc, char **argv) {
if(argc != 1) {
std::cout << argv[0] << "takes no arguments.\n";
return 1;
}
std::cout << "This is project " << PROJECT_NAME << ".\n";
auto env = lmdb::env::create();
env.set_max_dbs(10);
char dirname[] = "/tmp/lmdb-bug.XXXXXX";
env.open(mkdtemp(dirname));
lmdb::dbi db;
{
auto txn = lmdb::txn::begin(env);
db = lmdb::dbi::open(
txn, std::string("dupsort").c_str(), MDB_CREATE | MDB_DUPSORT);
lmdb::dbi_set_dupsort(txn, db, compare_state_key);
db.put(txn, "abcd", "ab,cdef");
db.put(txn, "abcd", "a,abc");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 5, data:
'" << data << "', expected: 'a,abc'\n";
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
db.put(txn, "abcd", "a,12");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 4, data:
'" << data << "', expected: 'a,12'\n";
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
db.put(txn, "abcd", "a,x");
txn.commit();
}
{
auto txn = lmdb::txn::begin(env);
std::string_view data;
db.get(txn, "abcd", data);
std::cout << "Data size: " << data.size() << " expected: 3, data:
'" << data << "', expected: 'a,x'\n";
txn.commit();
}
return 0;
}
This prints the following output:
This is project mdb-dup-bug.
Data size: 5 expected: 5, data: 'a,abc', expected: 'a,abc'
Data size: 5 expected: 4, data: 'a,12c', expected: 'a,12'
Data size: 5 expected: 3, data: 'a,x2c', expected: 'a,x'
Commenting out the first put with the different data-key resolves the issue,
but certainly you would expect that replacing a duplicate replaces the size
too. Doing explicit delete before the put works around 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=4501
--- Comment #5 from Fredrik Roubert <fredrik(a)roubert.name> ---
Java 1.5 is no longer sufficient to be able to build this code base using a
still supported JDK, so I propose updating the scope of this issue to Java 8
instead and then resolve that with this series of patches:
https://git.openldap.org/openldap/jdbcldap/-/merge_requests/6
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9887
Issue ID: 9887
Summary: Offer to mirror OpenLDAP
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mirrors(a)jevincanders.net
Target Milestone: ---
Greetings,
We're from Jevin Canders, a hosting company based in New York (servers are in
Buffalo).
We're wondering if you wanted/needed another US mirror. We're already mirroring
other open source projects, including Kali Linux and F-Droid. As of next week
(tentatively), our mirror server will have a 20 Gbps pipe to work with, so
we'll be able to handle new projects.
Let us know if you have any questions, concerns, or requests.
Sincerely,
Josh Anders and Kevin Croissant
JC Mirrors Team
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9956
Issue ID: 9956
Summary: Please register my company on the support page
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: sjsong(a)aboutdap.kr
Target Milestone: ---
Hello. openldap page administrater.
Please register my company on the support page.
Please contact me if you need additional information.
Registration phrase
Seojindsa Co., Ltd. (Aboutdap Co., Ltd.)- Korea
Provides consultancy, development, training and user support for OpenLDAP
software in Korea.
URL : seojindsa : www.seojindsa.kr, aboutdap : www.aboutdap.kr
thank you.
Song.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10010
Issue ID: 10010
Summary: password/sha2 produces incorrect SHA256
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: pmenzel+bugs.openldap.org(a)molgen.mpg.de
Target Milestone: ---
From [Debian BTS report #1030716](https://bugs.debian.org/1030716):
Dear Maintainer,
we got a report[1] on Ubuntu that the contrib module password/sha2 was
producing an incorrect SHA256 hash. It was confirmed for a number of
releases (22.04, 22.10 and the upcoming 23.04). I checked and it also
happens on current debian/sid:
$ slappasswd -s secret -h '{SHA256}' -o module-load=pw-sha2
{SHA256}WIrrpN3OjEVOUf6yrH1j+o+ODuUuNBo979Od4UXnu54=
$ echo "{SHA256}$(echo -n secret | openssl dgst -sha256 -binary |
openssl enc -base64)"
{SHA256}K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols=
The suggested fix was to rebuild just this module with
`-fno-strict-aliasing`, and indeed that fixed it in Ubuntu. Other
options include:
- finding the offending piece of code that is causing this
optimization to misbehave
- updating the module to use gnutls or openssl, whatever openldap ends
up being linked with
- not building/shipping this module
1. https://bugs.launchpad.net/bugs/2000817
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9912
Issue ID: 9912
Summary: slapd attempting free on address which was not
malloced
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: kimjuhi96(a)snu.ac.kr
Target Milestone: ---
Providing following command-line input results in invalid free.
./servers/slapd/slapd -h1 -h1
This issue exists in openldap-2.6.3 and the master branch of git.
Environment:
- Ubuntu 20.04
- clang-14.0.6 with CFLAGS="-fsanitize=address"
Backtrace:
=================================================================
==3323395==ERROR: AddressSanitizer: attempting free on address which was not
malloc()-ed: 0x7ffc8512c238 in thread T0
#0 0x4d0077
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
#1 0xb77152
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0xb77152)
#2 0x65ff02
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x65ff02)
#3 0x5168a9
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x5168a9)
#4 0x7ff21bd3c082 (/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#5 0x42130d
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x42130d)
Address 0x7ffc8512c238 is located in stack of thread T0 at offset 10072 in
frame
#0 0x515fef
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x515fef)
This frame has 10 object(s):
[32, 36) 'rc' (line 220)
[48, 52) 'syslogUser' (line 230)
[64, 72) 'waitfds' (line 234)
[96, 100) 'level' (line 402)
[112, 128) 'opt' (line 432)
[144, 148) 'opt393' (line 717)
[160, 168) 'errmsg' (line 726)
[192, 196) 'buf' (line 778)
[208, 336) 'ebuf' (line 798)
[368, 496) 'ebuf524' (line 821) <== Memory access at offset 10072 overflows
this variable
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
(longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: bad-free
(/home/juhee/project/foxfuzz/programs/network/openldap/servers/slapd/slapd+0x4d0077)
==3323395==ABORTING
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9951
Issue ID: 9951
Summary: lloadd can lock up in cn=monitor modify
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lload_monitor_conn_modify's callers have borrowed the cn=monitor entry from the
cache, however it also observes memory management, so if the connection is
released and it is the last thread around, it might be responsible for freeing
it via epoch_leave(). However freeing it also requires that the connection be
removed from cn=monitor and we can deadlock there.
A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9913
Issue ID: 9913
Summary: Some lloadd shutdown code doesn't protect memory
correctly
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
During shutdown, clients_destroy and tier_destroy are called while worker
threads might still be alive, therefore they need to participate in memory
management.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9907
Issue ID: 9907
Summary: lloadd config/shutdown leaks
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lloadd leaks some memory in cn=config and at shutdown time. Fixes coming
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9906
Issue ID: 9906
Summary: cn=monitor leaks in lloadd
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
lloadd registers various types of monitor_subsys_t but currently doesn't tear
all parts of them down correctly, leaking memory on server shutdown. Partly
down to how back-monitor shutdown works at the moment.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9045
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9931
Issue ID: 9931
Summary: test079 broken on MacOSX
Product: OpenLDAP
Version: 2.5.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Strictly-conforming getopt doesn't allow mixing of -options and plain args. All
documentation shows that LDAP attributes must be last on the ldapsearch
commandline, but the script is putting additional -options after the
olmDbConnURI attribute specification, which causes the following -options to be
ignored and the search command fails.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9991
Issue ID: 9991
Summary: slapd may close a connection twice
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If slapd is sending an entry to a client, and the client is sending an Unbind
request and disconnecting at the same time, send_ldap_ber() will get an error
attempting to write on the dead socket. It will then try to call
connection_closing() to close the connection. But the frontend may also have
gotten a read error on the dead socket, and handled the close there already.
By the time send_ldap_ber() acquires the c_mutex and actually calls
connection_closing(), the conn struct may have already been assigned to a new
connection, and the connection_closing() call will erroneously close an active
session.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9955
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.