https://bugs.openldap.org/show_bug.cgi?id=9551
Issue ID: 9551
Summary: dnSubtreeMatch and others do not handle empty DN as
asserted value
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
AFAIK '(reqDN:dnSubtreeMatch:=)' should be equivalent to 'reqDN=*', however it
only seems to match the empty dn right now.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9537
Issue ID: 9537
Summary: slap_timestamp() can give a duplicated timestamp
across restarts
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
On busy sites, when a slapd restart takes <1s, accesslog can fail to log
changes with LDAP_ALREADY_EXISTS. This is because slap_timestamp() only logs
timestamps with a 1s precision, disambiguating the rest with a counter that's
forgotten across restarts.
It is possible my analysis in ITS#9487 is partially invalidated because of
this.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9526
Issue ID: 9526
Summary: slapadd -w crashes
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Let slapd.conf is:
> database mdb
> suffix "o=Foo"
> sync_use_subentry
database is blank and we are adding this foo.ldif:
> dn: o=FOO
> objectClass:organization
Let's load:
> slapd -T add -v -l foo.ldif -w
then on Solaris:
> added: "o=FOO" (00000001)
> Segmentation Fault (core dumped)
... on Linux:
> added: "o=FOO" (00000001)
> => mdb_next_id: get failed: Invalid argument (22)
> => mdb_tool_next_id: next_id failed: Invalid argument (22)
> => mdb_tool_entry_put: txn_aborted! Invalid argument (22)
> slapadd: couldn't create context entry
> Closing DB...
This is because:
* mdb_tool_next_id() takes dead global [tools.c`static MDB_cursor *mcp] for
further operations
* cursor is dead because mdb_tool_entry_put() didn't initialized it
* mdb_tool_entry_put() didn't initialized cursor because it thinks it is
initialized, because there is an active global [tools.c`MDB_txn *mdb_tool_txn]
* transaction was initialized by mdb_tool_dn2id_get(), which doesn't care about
cursors.
Long story short: the global state in tools.c is not managed consistently and
needs rethinking.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6467
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=9552
Issue ID: 9552
Summary: slapo-accesslog should record new DN after rename
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
To use accesslog as a sessionlog source, one needs to be able to resolve
whether a modrdn moved an entry in/out of the search scope. Syncprov would
either have to examine every modrdn request or, if accesslog were to log the
final DN, it could check for entries which crossed the scope.
A new attribute 'reqNewDN' should be tracked for modrdn ops.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9529
Issue ID: 9529
Summary: pcache locking issue
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Since ITS#6954 commit ea228495148 the consistency_check function was changed
to hold the template t_rwlock for the entire duration of a query expiration.
There doesn't appear to be any valid reason for this change, and it causes
the cache to be unresponsive to new searches while expiration is removing
cached entries.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9295
Issue ID: 9295
Summary: ppolicy and replication: pwdLockedTime replication
fails to replicate
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If you have the following setup, a replica will hit an error during
replication.
a) ppolicy is configured on provider(s) and replicas. Replica has
schemachecking=on in its syncrepl configuration
b) account gets locked on the replica, so pwdAccountLockedTime is set on the
replica but not on the provider(s)
c) admin does a MOD/ADD op against a provider for the user entry to add a value
to pwdAccountLockedTime
dn: ...
changetype: modify
add: pwdAccountLockedTime
pwdAccountLockedTime: ...
d) provider accepts this modification.
e) replica rejects this modification because the resulting change means that
there would be two pwdAccountLockedTime values on the account in question
Generally I believe that in this scenario, the MOD/ADD on the provider should
be treated as a replace OP instead of an ADD op
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9530
Issue ID: 9530
Summary: double-free in options.c
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: norm.green(a)gemtalksystems.com
Target Milestone: ---
I've been seeing double-free errors in valgrind when calling
ldap_set_option(lc, LDAP_OPT_DEFBASE)
I tracked it down to code in ldap_create() in open.c.
When we copy the global options to the new LDAP *, we create new versions of
some but not all malloced options. The ldo_defbase and ldo_defbinddn option
members are strings that are *not* reallocated (ldo_defbase may not be
important).
This diff appears to fix the problem:
diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c
index 5882b6336..0828d334e 100644
--- a/libraries/libldap/open.c
+++ b/libraries/libldap/open.c
@@ -139,6 +139,14 @@ ldap_create( LDAP **ldp )
ld->ld_options.ldo_defludp = NULL;
ld->ld_options.ldo_conn_cbs = NULL;
+ /* Norm Green, April 20, 2021 - fix pointers that get copied.
+ * must realloc these to prevent double-free errors */
+
+ ld->ld_options.ldo_defbase = gopts->ldo_defbase ?
+ LDAP_STRDUP(gopts->ldo_defbase) : NULL;
+ ld->ld_options.ldo_defbinddn = gopts->ldo_defbinddn ?
+ LDAP_STRDUP(gopts->ldo_defbinddn) : NULL;
+
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9521
Issue ID: 9521
Summary: libldap doesn't configure TLS1.3 ciphersuites for
OpenSSL
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
OpenSSL 1.1 uses a separate API for configuring TLSv1.3 cipher suites.
The current code in libldap doesn't call this API so those suites are
always left at their compiled-in default.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9559
Issue ID: 9559
Summary: ldap_modify manpage LDAPMod incorrect
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
ldap_modify(3) suggests that struct ldapmod has a mod_next parameter, where
ldap.h defines no such thing, nor is it even mentioned in RFC1823 for what
that's worth.
So I think it is the manpage that needs updating.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8820
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=9554
Issue ID: 9554
Summary: Finish retiring configure.in in OpenLDAP 2.5 and later
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Update configure.in to configure.ac for contrib modules:
./contrib/ldaptcl/configure.in
./contrib/ldapc++/configure.in
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9561
Issue ID: 9561
Summary: Error doing 'make test': fails on 'test001-slapadd for
mdb' test
Product: OpenLDAP
Version: 2.5.4
Hardware: x86_64
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: sydbarrett74(a)gmail.com
Target Milestone: ---
FreeBSD 13.0 x86_64
I was attempting to build the latest version in the master git branch and when
I issued the 'gmake test' command, I got the following errors:
>>>>> Starting test001-slapadd for mdb...
running defines.sh
Running slapadd to build slapd database...
Fatal error 'mutex 0x801018040 own 0x0 is on list 0x5952414e49422d58
0x312e312e' at line 154 in file /usr/src/lib/libthr/thread/thr_mutex.c (errno =
0)
Abort trap (core dumped)
slapadd failed (134)!
>>>>> test001-slapadd failed for mdb after 1 seconds
(exit 134)
gmake[2]: *** [Makefile:301: mdb-yes] Error 134
gmake[2]: Leaving directory '/usr/home/bsduser/openldap/tests'
gmake[1]: *** [Makefile:287: test] Error 2
gmake[1]: Leaving directory '/usr/home/bsduser/openldap/tests'
gmake: *** [Makefile:299: test] Error 2
Please advise. TIA.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9548
Issue ID: 9548
Summary: argon2 module is not installed
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
2.5.4, configured with --enable-argon2. 'make install' installs the argon2 man
page, but not the module itself. Confirmed by Quanah.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9544
Issue ID: 9544
Summary: Compilation error when enabling SLAPI
Product: OpenLDAP
Version: 2.5.4
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: jcarmona(a)vmware.com
Target Milestone: ---
OpenLDAP 2.5.4 fails to build when enabling SLAPI support for SLAPD:
/bin/sh ../../../libtool --mode=compile cc -g -O2 -I../../../include -I.. -I.
-I../../../include -I./.. -I. -DSLAPI_LIBRARY -c plugin.c
libtool: compile: cc -g -O2 -I../../../include -I.. -I. -I../../../include
-I./.. -I. -DSLAPI_LIBRARY -c plugin.c -fPIC -DPIC -o .libs/plugin.o
plugin.c:37:16: error: unknown type name 'lt_dlhandle'; did you mean
'sa_handler'?
SLAPI_FUNC *, lt_dlhandle * );
^~~~~~~~~~~
sa_handler
plugin.c: In function 'plugin_pblock_new':
plugin.c:73:2: error: unknown type name 'lt_dlhandle'; did you mean
'sa_handler'?
lt_dlhandle hdLoadHandle;
^~~~~~~~~~~
sa_handler
plugin.c:103:7: warning: implicit declaration of function
'slapi_int_load_plugin'; did you mean 'slapi_int_get_plugins'?
[-Wimplicit-function-declaration]
rc = slapi_int_load_plugin( pPlugin, path, initfunc, 1, NULL, &hdLoadHandle
);
^~~~~~~~~~~~~~~~~~~~~
slapi_int_get_plugins
plugin.c: At top level:
plugin.c:557:2: error: unknown type name 'lt_dlhandle'; did you mean
'sa_handler'?
lt_dlhandle *pLdHandle )
^~~~~~~~~~~
sa_handler
make[3]: *** [Makefile:388: plugin.lo] Error 1
make[3]: Leaving directory '/wig/openldap-2.5.4/servers/slapd/slapi'
make[2]: *** [Makefile:524: slapi/libslapi.la] Error 2
make[2]: Leaving directory '/wig/openldap-2.5.4/servers/slapd'
make[1]: *** [Makefile:300: all-common] Error 1
make[1]: Leaving directory '/wig/openldap-2.5.4/servers'
make: *** [Makefile:321: all-common] Error 1
----
In order to reproduce it, simply download the latest release and use the flag
--enable-slapi when calling configure:
$ wget
https://www.openldap.org/software/download/OpenLDAP/openldap-release/openld…
$ tar xfz openldap-2.5.4.tgz && cd openldap-2.5.4
$ ./configure --enable-slapi
$ make depend
$ make
The compilation fails and binaries are not generated. This does not seem to
happen on version 2.4.58, whose compilation runs smoothly with this flag
activated.
Additional Information:
$ gcc --version
gcc (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ uname -a
Linux af3c371dbbbf 4.15.0-128-generic #131~16.04.1-Ubuntu SMP Wed Dec 9
17:33:47 UTC 2020 x86_64 GNU/Linux
$ date
Mon May 3 12:36:10 UTC 2021
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9541
Issue ID: 9541
Summary: Typos in ldap_pvt_gettimeofday() in
libraries/libldap/util-int.c
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: brecht(a)sanders.org
Target Milestone: ---
In openldap 2.544 there appear to be some typos in libraries/libldap/util-int.c
- there is an int between the ldap_pvt_gettimeofday() function definition and
the next curly brace
- tv_spec is not a member of struct timeval, should be tv_sec
patch -ulbf libraries/libldap/util-int.c << EOF
@@ -300,3 +300,2 @@
ldap_pvt_gettimeofday( struct timeval *tv, void *unused )
-int
{
@@ -304,3 +303,3 @@
ldap_pvt_clock_gettime( 0, &ts );
- tv->tv_sec = ts.tv_spec;
+ tv->tv_sec = ts.tv_sec;
tv->tv_usec = ts.tv_nsec / 1000;
EOF
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9555
Issue ID: 9555
Summary: Introduce a default operations timeout for
back-asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Currently, if no operation timeout is configured, the default asyncmeta
behavior is to have no timeout. This is potentially unsafe - if for some reason
a target server does not return a response, the operation will stay in the
queue until the connection is reset due to some network error (idle-timeout is
not honored if there are pending operations). In the case of many such
operations, the queues can get filled up and asyncmeta will become unable to
process new operations for some time.
Therefore, a setting of "0" should be used carefully and with intent. To
prevent accidental configuration of 0, the default operations timeout should be
a value larger than 0.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9531
Issue ID: 9531
Summary: change RootDSE
Product: OpenLDAP
Version: 2.4.57
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: niko(a)dwolfix.ru
Target Milestone: ---
Created attachment 816
--> https://bugs.openldap.org/attachment.cgi?id=816&action=edit
RootDSE
OS Linux Debian 10, slapd 2.4.57+dfsg-2
When installing openldap, a RootDSE is formed with the objectClass
'organization' (2.5.6.4). The root entry cannot be deleted.
How can the RootDSE be changed so that the objectClass becomes 'domain'
(0.9.2342.19200300.100.4.13)?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8721
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
Resolution|TEST |FIXED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6683
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |quanah(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6531
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Severity|normal |enhancement
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6289
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|ondra(a)mistotebe.net |hyc(a)openldap.org
--
You are receiving this mail because:
You are on the CC list for the issue.