openldap-bugs August 2020

openldap-bugs@openldap.org

2 participants
185 discussions

[Issue 9269] New: "hidden" "subordinate" database is shown in a directory tree
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9269 Issue ID: 9269 Summary: "hidden" "subordinate" database is shown in a directory tree 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: --- "hidden" configuration option is ignored by slapd (not honored by "glue" overlay?) if the database it tries to hide is also a "subordinate" database. Checked for openldap 2.4.47 and current git master (f3952d9). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

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.

1 13

[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

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.

1 10

[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9221 Bug ID: 9221 Summary: Move all replication consumer code into its own overlay 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: --- (In relation to a discussion about slapo-chain) <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay <hyc> in that case, updateref would be processed wherever the overlay was configured <hyc> so no longer tied to the frontend <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref) <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent 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: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 9278] New: liblmdb: robust mutexes should not be unmapped
by openldap-its＠openldap.org 23 Oct '23

23 Oct '23

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 20

[Bug 9256] New: The ACLs required for SASL binding are not fully documented
by openldap-its＠openldap.org 28 Feb '22

28 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9256 Bug ID: 9256 Summary: The ACLs required for SASL binding are not fully documented Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 727 --> https://bugs.openldap.org/attachment.cgi?id=727&action=edit Patch massaging the SASL binding requirement docs While some ACL requirements for SASL binding are documented, some are not. E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is not documented. Other requirements can be reasoned out based on the existing documentation, but this can be very difficult when unfamiliar with all the moving parts and the places they are documented. E.g. knowing that (objectClass=*) is the default filter, and that there's _always_ _some_ filter, and connecting this with ACLs required to do search-based SASL mapping. The attached patch brings all the SASL binding requirements together in one place in the docs and makes everything explicit. The word "SASL" is included, for those searching for that keyword. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org 18 Feb '22

18 Feb '22

https://bugs.openldap.org/show_bug.cgi?id=9189 Bug ID: 9189 Summary: Add GSSAPI channel-bindings support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: iboukris(a)gmail.com Target Milestone: --- Recently MS has announce they plan to enforce channel-bindings for LDAP over TLS (ADV190023). To support it on client side, we need to pass "tls-endpoint" bindings (RFC 5929) to the SASL plugin, and make use of that in GSSAPI. See also: https://github.com/cyrusimap/cyrus-sasl/pull/601 -- You are receiving this mail because: You are on the CC list for the bug.

1 13

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2020