https://bugs.openldap.org/show_bug.cgi?id=10003
Issue ID: 10003
Summary: Potential Use After Free in libraries/libldap/open.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 Use After Free in open.c line 590.
Doc says "Once it(ldap_unbind) is called, the connection to the LDAP server
is closed, and the ld structure is invalid."
in
https://www.openldap.org/software/man.cgi?query=ldap_unbind_ext&apropos=0&s…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9998
Issue ID: 9998
Summary: Potential memory leak in tests/progs/slapd-mtread.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-mtread.c line 520.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=10048
Issue ID: 10048
Summary: adding a regex entry for overlay variant crashes slapd
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: stefan(a)kania-online.de
Target Milestone: ---
I'm using symas-packages 2.6.4 on a Debian 11 system. Two providers with multi
provider replication.
I try to add different entries wit overlay "variant" first without regex. Here
my ldif for the configuration:
-----------
dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: variant.la
-----------
-----------
dn: olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantConfig
olcVariantPassReplication: TRUE
dn: name=global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantVariant
olcVariantEntry: dc=example,dc=net
dn:
olcVariantVariantAttribute=postaladdress,name={0}global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantAttribute
olcVariantVariantAttribute: postaladdress
olcVariantAlternativeAttribute: postaladdress
olcVariantAlternativeEntry: ou=firma,dc=example,dc=net
dn:
name=company-phone,name={0}global-addr,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantAttribute
olcVariantVariantAttribute: telephonenumber
olcVariantAlternativeAttribute: mobile
olcVariantAlternativeEntry:
cn=verw-al,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net
-----------
That works as expected.
Then I wrote a ldif-file for variant WITH regex:
-----------
dn: name=verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantRegex
olcVariantEntryRegex: cn=.+,ou=users,ou=verwaltung,ou=firma,dc=example,dc=net
dn:
olcVariantVariantAttribute=telephonNumber,name={1}verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config
objectClass: olcVariantAttributePattern
olcVariantVariantAttribute: telephoneNumber
olcVariantAlternativeAttribute: telephoneNumber
olcVariantAlternativeEntryPattern: ou=Verwaltung,ou=firma,dc=example,dc=net
-----------
When I try to add the ldif with ldapadd slapd crashes with the following
messages in the log:
---------------
May 06 08:16:28 provider02 slapd[8018]: conn=1001 fd=20 ACCEPT from
PATH=/var/symas/run/ldapi (PATH=/var/symas/run/ldapi)
May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND dn="" method=163
May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND
authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth"
May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 BIND
dn="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" mech=EXTERNAL
bind_ssf=0 ssf=71
May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=0 RESULT tag=97 err=0
qtime=0.000009 etime=0.000146 text=
May 06 08:16:28 provider02 slapd[8018]: conn=1001 op=1 ADD
dn="name=verw-tel,olcOverlay={2}variant,olcDatabase={2}mdb,cn=config"
May 06 08:16:28 provider02 slapd[8018]: slap_get_csn: conn=1001 op=1 generated
new csn=20230506081628.055320Z#000000#001#000000 manage=1
May 06 08:16:28 provider02 slapd[8018]: slap_queue_csn: queueing 0x7f7c64012890
20230506081628.055320Z#000000#001#000000
May 06 08:16:28 provider02 slapd[8018]: olcVariantEntryRegex: value #0:
<olcVariantEntryRegex> handler exited with 19!
May 06 08:16:28 provider02 systemd[1]: symas-openldap-server.service: Main
process exited, code=killed, status=11/SEGV
May 06 08:16:28 provider02 systemd[1]: symas-openldap-server.service: Failed
with result 'signal'.
---------------
Even if olcVariantEntryRegex is wrong (what I don't know up to now) slapd
should not crash.
--
You are receiving this mail because:
You are on the CC list for the issue.
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=10037
Issue ID: 10037
Summary: Instructions for building argon2.so are inaccurate
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: sclassen(a)lbl.gov
Target Milestone: ---
The instructions for building the argon2.so shared library are inaccurate.
According to: servers/slapd/pwmods/README.argon2
Building
--------
1) Customize the OPENLDAP variable in Makefile to point to the OpenLDAP
source root.
For initial testing you might also want to edit DEFS to define
SLAPD_ARGON2_DEBUG, which enables logging to stderr (don't leave this on
in production, as it prints passwords in cleartext).
2) Run 'make' to produce argon2.so
3) Copy argon2.so somewhere permanent.
4) Edit your slapd.conf (eg. /etc/ldap/slapd.conf), and add:
moduleload ...path/to/argon2.so
5) Restart slapd.
When I run make from within servers/slapd/pwmods/ I get the following error:
[user@machine openldap-2.6.4]# cd servers/slapd/pwmods/
[user@machine pwmods]# make
make: *** No rule to make target 'dummyvalue', needed by 'all-common'. Stop.
I’m not sure what “dummyvalue” is supposed to be so I commented out line 288 in
servers/slapd/pwmods/Makefile
# LIBRARY = dummyvalue
And get this error:
[user@ machine pwmods]# make
/bin/sh ../../../libtool --tag=disable-static --mode=compile cc -g -O2
-I../../../include -I../../../include -I.. -I./.. -DSLAPD_IMPORT -c
version.c
libtool: compile: cc -g -O2 -I../../../include -I../../../include -I.. -I./..
-DSLAPD_IMPORT -c version.c -fPIC -DPIC -o .libs/version.o
version.c:1:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘:’ token
usage: mkversion [-c] [-s] [-p package] [-v version] application
^
make: *** [Makefile:310: version.lo] Error 1
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10033
Issue ID: 10033
Summary: olcDbCacheSize in mdb configuration example
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: stefan(a)kania-online.de
Target Milestone: ---
on Page:
https://openldap.org/doc/admin26/overlays.html#The%20Proxy%20Cache%20Engine
There is an example for pcache-db configuration for a mdb-database:
-----------
dn: olcDatabase={0}mdb,olcOverlay={0}pcache,olcDatabase={2}ldap,cn=config
objectClass: olcMdbConfig
objectClass: olcPcacheDatabase
olcDatabase: {0}mdb
olcDbDirectory: ./testrun/db.2.a
olcDbCacheSize: 20
olcDbIndex: objectClass eq
olcDbIndex: cn,sn,uid,mail pres,eq,sub
-----------
But olcDbCacheSize is an bdb/hdb attribute.
--
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.