https://bugs.openldap.org/show_bug.cgi?id=10067
Issue ID: 10067
Summary: back-meta doesn't like an empty modify
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: ---
A modify like:
dn: <dn>
changetype: modify
sent to a back-meta DB will trigger an assert on ch_malloc(0). The code also
kind of takes liberty at equating free and ch_free, which could backfire under
some (extremely rare) circumstances.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10081
Issue ID: 10081
Summary: slapacl lists wrong permissions when peername.ip is
used in ACL
Product: OpenLDAP
Version: 2.5.14
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: carsten.jaeckel(a)tu-dortmund.de
Target Milestone: ---
in a testing environment (SLES 15 SP5, OpenLDAP 2.5.14) I use the following
ACLs in olcAccess:
{0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by *
none {1}to * by group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by *
none break {2}to * by self read by anonymous auth by * none break
If I run ldapmodify -xWD "cn=test,ou=users,dc=foo,dc=bar" to change the account
cn=test,ou=users,dc=foo,dc=bar on the system with ip 10.10.10.10 everything
works as expected.
LDAP-Log:
2023-06-16T12:53:12.024030+02:00 tst1 slapd[1333]: conn=1016 fd=28 ACCEPT from
IP=10.10.10.10:53558 (IP=0.0.0.0:636)
2023-06-16T12:53:12.039643+02:00 tst1 slapd[1333]: conn=1016 fd=28 TLS
established tls_ssf=128 ssf=128 tls_proto=TLSv1.3
tls_cipher=TLS_AES_128_GCM_SHA256
2023-06-16T12:53:12.039773+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND
dn="cn=test,ou=users,dc=foo,dc=bar" method=128
2023-06-16T12:53:12.039841+02:00 tst1 slapd[1333]: conn=1016 op=0 BIND
dn="cn=test,ou=users,dc=foo,dc=bar" mech=SIMPLE bind_ssf=0 ssf=128
2023-06-16T12:53:12.041918+02:00 tst1 slapd[1333]: conn=1016 op=0 RESULT tag=97
err=0 qtime=0.000014 etime=0.002242 text=
2023-06-16T12:53:30.488074+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD
dn="cn=test,ou=users,dc=foo,dc=bar"
2023-06-16T12:53:30.488474+02:00 tst1 slapd[1333]: conn=1016 op=1 MOD
attr=description
2023-06-16T12:53:30.557458+02:00 tst1 slapd[1333]: conn=1016 op=1 RESULT
tag=103 err=0 qtime=0.000022 etime=0.069664 text=
2023-06-16T12:53:33.035486+02:00 tst1 slapd[1333]: conn=1016 fd=28 closed
(connection lost)
Running the above command from another machine results in a Insufficient access
(50) error as also expected.
So I assume the ACLs to be working correctly.
If I run
slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D
cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar on the system
with ip 10.10.10.10 I get the following output:
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "DC" inserted.
authcDN: "cn=test,ou=users,dc=foo,dc=bar"
entry: none(=0)
children: none(=0)
description=test: none(=0)
cn=test: none(=0)
sn=test: none(=0)
objectClass=person: none(=0)
objectClass=top: none(=0)
structuralObjectClass=person: none(=0)
entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: none(=0)
creatorsName=cn=manager,dc=foo,dc=bar: none(=0)
createTimestamp=20230227131940Z: none(=0)
userPassword=****: none(=0)
pwdChangedTime=20230227131959Z: none(=0)
authTimestamp=20230616065542Z: none(=0)
pwdLastSuccess=20230616103806Z: none(=0)
entryCSN=20230616103806.257186Z#000000#000#000000: none(=0)
modifiersName=cn=test,ou=users,dc=foo,dc=bar: none(=0)
modifyTimestamp=20230616103806Z: none(=0)
I expected to see write access in slapacl's output.
If I remove the 'peername.ip="10.10.10.10"' part from olcAccess {0}to
dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" peername.ip="10.10.10.10" write by *
none the above slapacl command outputs write access correctly no matter if the
parameter '-o peername=10.10.10.10' is set or not.
olcAccess:
{0}to dn.exact="cn=test,ou=users,dc=foo,dc=bar" by
dn.exact="cn=test,ou=users,dc=foo,dc=bar" write by * none {1}to * by
group.exact="cn=Admins,ou=groups,dc=foo,dc=bar" manage by * none break {2}to *
by self read by anonymous auth by * none break
slapacl -F /etc/symas/etc/openldap/slapd.d -o peername=10.10.10.10 -D
cn=test,ou=users,dc=foo,dc=bar -b cn=test,ou=users,dc=foo,dc=bar
PROXIED attributeDescription "OU" inserted.
PROXIED attributeDescription "DC" inserted.
authcDN: "cn=test,ou=users,dc=foo,dc=bar"
entry: write(=wrscxd)
children: write(=wrscxd)
description=first test
cn=test: write(=wrscxd)
sn=test: write(=wrscxd)
objectClass=person: write(=wrscxd)
objectClass=top: write(=wrscxd)
structuralObjectClass=person: write(=wrscxd)
entryUUID=2304877c-4aed-103d-8c25-b91c1e3518c8: write(=wrscxd)
creatorsName=cn=manager,dc=foo,dc=bar: write(=wrscxd)
createTimestamp=20230227131940Z: write(=wrscxd)
userPassword=****: write(=wrscxd)
pwdChangedTime=20230227131959Z: write(=wrscxd)
authTimestamp=20230616065542Z: write(=wrscxd)
pwdLastSuccess=20230616105312Z: write(=wrscxd)
entryCSN=20230616105330.487886Z#000000#000#000000: write(=wrscxd)
modifiersName=cn=test,ou=users,dc=foo,dc=bar: write(=wrscxd)
modifyTimestamp=20230616105330Z: write(=wrscxd)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10047
Issue ID: 10047
Summary: slapd SEGV after slapindex -q
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In an environment where cn=config is replicated:
a) Added an equality index for an existing attribute
b) Stopped slapd after the change to the configuration had been replicated to
the server. The indexing process that was automatically kicked off by this had
been running for ~30 minutes before I stopped slapd
c) ran: slapindex -q -F /path/to/config -b <base> <attr>
d) started slapd
e) segfault
To verify it wasn't an overall data issue, I then:
a) slapcat the database
b) moved the problem database files aside for debugging
c) reloaded the database with slapadd -q
d) everything works fine
I will attach the gdb output to this ticket momentarily
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10042
Issue ID: 10042
Summary: Crash when back-monitor search fails/is abandoned
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The fix in ITS#9832 was incomplete, some paths leading to "freeout:" can have
passed through monitor_cache_release already.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9993
Issue ID: 9993
Summary: Potential race condition in back-mdb online indexer
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the online indexer completes, it should mutex-protect its resetting of the
indexing flags.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10063
Issue ID: 10063
Summary: Typo in configure.ac for SLAPD_DYNAMIC_PWMODS
Product: OpenLDAP
Version: 2.6.3
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
As noted in -technical discussion:
By the way, while looking at the code, I noticed a typo in configure.ac:
> if test "$ol_enable_argon2" = "yes" ; then
> SLAPD_DYNAMIC_PWMODS="$SLAPD_DYNAMIC_PWDMODS argon2.la"
> fi ^^ ^^^
It's referencing two different variables there, which is harmless today,
but will be a build bug once multiple password modules become available.
SLAPD_DYNAMIC_PWMODS is the correct one.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10039
Issue ID: 10039
Summary: configure fails to detect
SSL_export_keying_material_early with LibreSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: orbea(a)riseup.net
Target Milestone: ---
Created attachment 957
--> https://bugs.openldap.org/attachment.cgi?id=957&action=edit
config.log
When configuring OpenLDAP using --with-tls=openssl with LibreSSL the configure
will fail to detect SSL_export_keying_material_early since LibreSSL doesn't
support this function yet. However OpenLDAP doesn't actually use this function
so this can be easily solved by checking for SSL_library_init which is a more
standard function which both OpenSSL and LibreSSL support which OpenLDAP
actually uses in libraries/libldap/tls_o.c.
checking openssl/ssl.h usability... yes
checking openssl/ssl.h presence... yes
checking for openssl/ssl.h... yes
checking for SSL_export_keying_material_early in -lssl... no
configure: error: Could not locate TLS/SSL package
Other than this the build succeeds correctly with at least LibreSSL 3.7.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9995
Issue ID: 9995
Summary: Potential memory leak in clients/tools/ldapdelete.c
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: 1061499390(a)qq.com
Target Milestone: ---
Version: Github:master
Potential memory leak in ldapdelete.c line 384.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=10032
Issue ID: 10032
Summary: at_add returns a free'd pointer on error
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
When an invalid schema is provided (e.g. the current
./servers/slapd/schema/msuser.schema of memberof/dynlist is loaded already),
at_add() hits error handling and frees at->at_oid, but that string is being
returned in *err. A fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.