[Issue 9278] New: liblmdb: robust mutexes should not be unmapped
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9278
Issue ID: 9278
Summary: liblmdb: robust mutexes should not be unmapped
Product: LMDB
Version: unspecified
Hardware: All
OS: FreeBSD
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: delphij(a)freebsd.org
Target Milestone: ---
Created attachment 736
--> https://bugs.openldap.org/attachment.cgi?id=736&action=edit
A possible workaround
We recently noticed that lmdb would have the memory region containing the
robust mutex unmapped on mdb_env_close0():
munmap((void *)env->me_txns,
(env->me_maxreaders-1)*sizeof(MDB_reader)+sizeof(MDB_txninfo));
Note that if this is the last unmap for a robust mutex, the FreeBSD
implementation would garbage-collect the mutex, making it no longer visible to
other processes. As the result, a second instance of the attached test.c (from
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=244493 with minor changes)
would trigger the assertion at mdb_txn_begin() because the acquisition of the
mutex would return 22 (EINVAL), because the mutex appeared to be a robust
mutex, but was invalid.
The attached lmdb.diff is a possible workaround for this (it would skip
unmapping when setting up the robust mutex for the first time).
--
You are receiving this mail because:
You are on the CC list for the issue.
1 week, 6 days
[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9244
Bug ID: 9244
Summary: API calls blocking after async connect
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
Created attachment 721
--> https://bugs.openldap.org/attachment.cgi?id=721&action=edit
async connect test without TLS
My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should
not block. If the connection does not establish fast enough, the bind call is
supposed to return LDAP_X_CONNECTING.
(At least that's how I understand it, based on the original behaviour (circa
2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand,
the man page does "Subsequent calls to library routines will poll for
completion of the connect before performing further operations" which might be
interpreted as meaning they would block...)
In current releases it does block, as demonstrated by strace on Linux (latency
added using 'tc qdisc'):
[...]
connect(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in
progress)
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14
poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "0\f\2\1\1a\7\n", 8) = 8
read(3, "\1\0\4\0\4\0", 6) = 6
write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned
0 (Success)
) = 42
[...]
As discussed in IRC, I believe I bisected this down to commit ae6347bac, from
bug 8022. The reasoning is sound, but ldap_int_open_connection does not
actually return -2, only -1 or 0.
The patch is simple enough, but I'm also looking at some later commits that
were probably done to work around this, and might not be needed now (bug 8957,
bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps,
STARTTLS, not to mention back-meta/asyncmeta).
I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless
LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page
doesn't mention this specifically, and I don't see why it would be necessary...
--
You are receiving this mail because:
You are on the CC list for the bug.
2 weeks
[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9229
Bug ID: 9229
Summary: Make liblutil usable by libldap
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
liblutil is a static library (non-PIC) and so cannot be linked into shared
objects, however we have several use cases for reusing its code in libldap.
Some options:
- moving more code from liblutil to libldap
- just merge the whole thing?
- are there components that link liblutil but _not_ libldap?
- build liblutil as PIC (take a minor performance hit when linked into
programs?)
- build liblutil twice (liblutil.a and liblutil_pic.a)
- symlink liblutil sources into libldap build dir, like libldap_r does with
libldap
- both of these last options require checking whether executables can call
the PIC symbols safely (if some symbols are used by both library and program
code)
Nice-to-have for 2.5, I'd say more likely for 2.6 at this point.
--
You are receiving this mail because:
You are on the CC list for the bug.
3 weeks, 3 days
[Issue 9436] New: OpenSSL 3.0: libldap uses depreciated functions
by openldap-its＠openldap.org
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.
1 month, 1 week
[Issue 9343] New: Expand ppolicy policy configuration to allow URL filter
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
4 months, 4 weeks
[Issue 9365] New: Mem leaks with Æ-DIR providers
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9365
Issue ID: 9365
Summary: Mem leaks with Æ-DIR providers
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Created attachment 772
--> https://bugs.openldap.org/attachment.cgi?id=772&action=edit
valgrind output on openSUSE Tumbleweed x86_64
An Æ-DIR installation with self-compiled OpenLDAP 2.4.53 on Debian (now
buster) has memory leak issues on the Æ-DIR providers. The read-only
consumers do not have this issue. The provider config is more complex
with more overlays and more ACLs.
In this production deployment slapd is automatically restarted (by monit) when
memory consumption reaches 80%. Thus monitoring clearly shows a frequent saw
tooth pattern.
I've also tested on openSUSE Tumbleweed x86_64 with a RE24 build [1] by running
slapd under control of valgrind for a couple of minutes continously sending
simple bind operations (additional to the monitoring and other back-ground jobs
running).
Find valgrind output of my first attempt attached.
Does that make sense at all?
--
You are receiving this mail because:
You are on the CC list for the issue.
8 months, 1 week
[Issue 9339] New: Add syncrepl status in cn=monitor
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9339
Issue ID: 9339
Summary: Add syncrepl status in cn=monitor
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Patch coming to expose some consumer state in cn=monitor
Sample entry:
# Consumer 001, database 2, databases, monitor
dn: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
objectClass: olmSyncReplInstance
structuralObjectClass: olmSyncReplInstance
cn: Consumer 001
creatorsName:
modifiersName:
createTimestamp: 20200906160447Z
modifyTimestamp: 20200906160447Z
olmSRProviderURIList: ldap://localhost:9011/
olmSRIsConnected: TRUE
olmSRSyncPhase: Persist
olmSRLastConnect: 20200906160448Z
olmSRLastContact: 20200906160453Z
olmSRLastCookieRcvd: rid=001,sid=001,csn=20200906160453.039573Z#000000#001#000
000
olmSRLastCookieSent: rid=001,sid=002,csn=20200906160447.723677Z#000000#001#000
000
entryDN: cn=Consumer 001,cn=database 2,cn=databases,cn=monitor
subschemaSubentry: cn=Subschema
hasSubordinates: FALSE
--
You are receiving this mail because:
You are on the CC list for the issue.
8 months, 4 weeks
[Issue 9437] New: Add OTP module to core
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9437
Issue ID: 9437
Summary: Add OTP module to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its OTP module for OpenLDAP 2.5 as a core overlay
--
You are receiving this mail because:
You are on the CC list for the issue.
8 months, 4 weeks
[Issue 9438] New: Add remoteauth overlay to core
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9438
Issue ID: 9438
Summary: Add remoteauth overlay to core
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Symas will contribute its remoteauth overlay for OpenLDAP 2.5 as a core overlay
--
You are receiving this mail because:
You are on the CC list for the issue.
8 months, 4 weeks
[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
9 months, 1 week