https://bugs.openldap.org/show_bug.cgi?id=10015
Issue ID: 10015
Summary: Config File KEEPALIVE_IDLE KEEPALIVE_PROBES
KEEPALIVE_INTERVAL parser does random memory write
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: sean(a)teletech.com.au
Target Milestone: ---
In openldap/libraries/libldap/init.c: [master branch]
The Config File integers
KEEPALIVE_IDLE
KEEPALIVE_PROBES
KEEPALIVE_INTERVAL
Should be struct ol_attribute.type ATTR_OPT_INT rather than ATTR_INT.
ATTR_INT interprets struct ol_attribute.offset as a pointer to integer.
ATTR_OPT_INT interprets struct ol_attribute.offset as an option number to be
passed to ldap_set_option()
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10016
Issue ID: 10016
Summary: syncprov may abandon a psearch improperly
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When processing an Abandon, it may remove the detached search op from the
connection while the qtask is actively sending search responses on the
connection. If the Abandon is due to an Unbind or connection loss, the
connection structure may get reused by a new conn while the qtask is still
running.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9953
Issue ID: 9953
Summary: Push replication issue for the pwdHistory attribute
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: dh(a)dotlan.net
Target Milestone: ---
Hello,
I'm using a master ldap instance with a push replication instance to external
slaves using the ldap backend on Debian 11 (2.4.57) and I came across some
replication issues that forces me to drop the slave dbs and do a manually
fullsync everything this error occurs.
The problem
===========
I know that replication and maintaining a password policy is a complicated
task, especially since the ppolicy overlay must be loaded and active in every
instance (master, push instance, slave). This problem leads to interesting
challanges.
First, I encountered a problem where pwdChangedTime would be duplicate because
the ppolicy overlay of the push instance and the back_ldap/slave instance would
like to set it (which leads to a duplicate attribute error). To fix problem I
backported the patch [1] to my local version of the slapd packages. After this
problem was fixed, I've encountered the next problematic attribute:
"pwdHistory". I've play around with some syncrepl settings, but in the end, it
seems to be a similar issue. It looks likes the pwdHistory attribute is not yet
present on the slave and both instances (push and slave) try to add the
pwdHistory Attributes which leads to a problem where both entries collied
(pwdHistory: value #0 already exists). For whatever reason pwdHistory doesn't
show up as modified field on the slave in the MOD request. But anyways.
Something seems to be wrong, and it could a similar replication issue compared
with pwdChangedTime
I've lookup into the change history of the ppolicy.c file in the 2.5 and 2.6
branch but couldn't find a newer commit that would address this issue.
Does anyone has encountered a similar issue? I've not played around with the
2.5 or 2.6 version, but looking at the code, I've either not seen a fix or the
problem might still exist, hopefully I am wrong. Any suggestions?
--
best regards
Daniel Hoffend
[1]
https://github.com/openldap/openldap/commit/7a34f46d1cabe8e80937d5167b62152…
Setup
=====
Host Master
- Debian 11 slapd 2.4.57+dfsg-3
- slapd master instance with cn=config
- push replikation instance with simple config (syncrepl from localhost, write
to backend ldap)
Host Slave
- Debian 11 slapd 2.4.57+dfsg-3
- Readonly slave
On all 3 instances ppolicy is enabled otherwise the operational attributes
would be not known/available and sync of locked accounts or per account
selected password policy assignment wouldn't work.
PUSH Replication Instance
=========================
database ldap
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
syncrepl rid=__RID__
provider=ldap://localhost:389/
binddn="cn=replication,ou=system,dc=example,dc=org"
bindmethod=simple
credentials="secret"
searchbase="dc=example,dc=org"
type=refreshAndPersist
schemachecking=off
retry="5 12 60 +"
attrs="*,memberOf,pwdPolicySubentry,pwdChangedTime,pwdAccountLockedTime,pwdHistory,creatorsName,createTimestamp,modifiersName,modifyTimestamp"
---
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_message_to_entry: rid=016
DN: uid=user1,ou=accounts,dc=example,dc=org, UUID:
db720f56-df0d-103c-8635-9543ccd6e97d
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) csn=(none) tid a0a89700
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_search
(0)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016
uid=user1,ou=accounts,dc=example,dc=org
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_null_callback : error code
0x14
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
uid=user1,ou=accounts,dc=example,dc=org (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: syncrepl_entry: rid=016 be_modify
failed (20)
Nov 3 00:00:45 ldapmaster slapd[2308611]: do_syncrepl: rid=016 rc 20 retrying
SLAVE LDAP Server
=================
database mdb
[...]
overlay ppolicy
ppolicy_default "cn=default,ou=policies,dc=example,dc=org"
---
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SRCH
base="uid=user1,ou=accounts,dc=example,dc=org" scope=0 deref=0
filter="(objectClass=*)"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176499 op=59513 SEARCH RESULT
tag=101 err=0 nentries=1 text=
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
dn="uid=user1,ou=accounts,dc=example,dc=org"
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 MOD
attr=structuralObjectClass creatorsName createTimestamp userPassword
pwdChangedTime memberOf entryCSN modifiersName modifyTimestamp
Nov 3 00:00:45 ldapslave slapd[2221506]: conn=176500 op=59513 RESULT tag=103
err=20 text=modify/add: pwdHistory: value #0 already exists
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10004
Issue ID: 10004
Summary: Potential memory leak in
libraries/librewrite/ldapmap.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapmap.c line 310, 321.Calling ldap_initialize()
without calling ldap_unbind_ext() to free the memory will cause a memory leak.
There is no ldap_unbind_ext before calling ldap_initialize in line 376, and the
ld will be allocated again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9999
Issue ID: 9999
Summary: Potential memory leak in tests/progs/slapd-search.c
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: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-search.c line 207.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=9996
Issue ID: 9996
Summary: Potential memory leak in
libraries/librewrite/ldapmap.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapmap.c line 359.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=10000
Issue ID: 10000
Summary: Potential memory leak in tests/progs/slapd-watcher.c
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: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in slapd-watcher.c line 517.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=10011
Issue ID: 10011
Summary: Incompatibilities with stricter C99 compilers
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: sam(a)gentoo.org
Target Milestone: ---
Newer C compilers (>= Clang 16 and likely >= GCC 14) reject some constructs
removed in C99 like implicit function declarations and implicit ints. Some
compilers are also starting to reject obsolete K&R prototypes which were
removed in C23.
I've filed an MR at
https://git.openldap.org/openldap/openldap/-/merge_requests/605 to address the
issues in configure as well as a small number of issues in the codebase itself.
For more information, see LWN.net [0] or LLVM's Discourse [1], the Gentoo wiki
[2],
or the (new) c-std-porting mailing list [3].
[0] https://lwn.net/Articles/913505/
[1]
https://discourse.llvm.org/t/configure-script-breakage-with-the-new-werror-…
[2] https://wiki.gentoo.org/wiki/Modern_C_porting
[3] hosted at lists.linux.dev.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9736
Issue ID: 9736
Summary: pwrite bug in OSX breaking LMDB promise about the
maximum value size
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Hi,
I was working with LMDB and found an issue when trying to write a value of
approximately 3.3GiB in the database, I dive into the LMDB source code of the
mdb_put method using the lldb debugger and found out that it was not related to
an issue in LMDB itself but rather a bug in the pwrite function of the Mac OS
libc implementation.
The pwrite function is given four parameters, the file descriptor, the buffer,
the count of bytes to write from the buffer and, the offset of where to write
it in the file. On Mac OS the count of bytes is a size_t that must be a 64bits
unsigned integer but when you call pwrite with a number bigger or equal to 2^31
it returns an error 22 (invalid argument). LMDB was returning a 22 error from
the mdb_put call and not an EINVAL because the error was cause by an internal
issue and not something catchable by LMDB.
I am not sure about what we can do, can we implement this single pwrite [1] as
multiple pwrite with counts smaller than 2^31 in a loop, just for Mac OS? Like
for Windows where we do specific things for this operating system too?
I also found this issue on the RocksDB repository [2] about a similar problem
they have with pwrite and write on Mac OS it seems. I understand that this is
not a real promise that LMDB is specifying but rather an "in theory" rule [3].
Thank you for your time,
kero
[1]:
https://github.com/LMDB/lmdb/blob/01b1b7dc204abdf3849536979205dc9e3a0e3ece/…
[2]: https://github.com/facebook/rocksdb/issues/5169
[3]: http://www.lmdb.tech/doc/group__mdb.html#structMDB__val
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9436
Issue ID: 9436
Summary: OpenSSL 3.0: libldap uses depreciated functions
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
OpenLDAP master fails to build against OpenSSL 3.0 alpha when "no-deprecated"
is specified.
Currently hitting these errors:
./.libs/libldap.so: undefined reference to `SSL_get_peer_certificate'
./.libs/libldap.so: undefined reference to `PEM_read_bio_DHparams'
./.libs/libldap.so: undefined reference to `ERR_get_error_line'
./.libs/libldap.so: undefined reference to `DH_free'
./.libs/libldap.so: undefined reference to `SSL_CTX_set_tmp_dh'
Notes:
SSL_get_peer_certificate is SSL_get1_peer_certificate in 3.0.0
SSL_CTX_set_tmp_dh should be replaced as follows:
# define SSL_CTX_set_tmp_dh(ctx,dh) \
SSL_CTX_ctrl(ctx,SSL_CTRL_SET_TMP_DH,0,(char *)(dh))
Have to dig deeper for:
PEM_read_bio_DHparams
ERR_get_error_line
DH_free
--
You are receiving this mail because:
You are on the CC list for the issue.