https://bugs.openldap.org/show_bug.cgi?id=10363
Issue ID: 10363
Summary: Implement a target connection time-to-live in
asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Implement a feature that limits the maximum time before a target connection is
reset, even if it is not idle - conn-ttl. To avoid too many target connections
timing out at once, a minimum reset interval per target should also be
configurable. So, a configuration of:
conn-ttl 5s 5s
would mean connections have a 5 seconds time-to-live, but a connection should
be reset no more frequently that once every 5 seconds per target.
This feature was requested by a customer.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10355
Issue ID: 10355
Summary: mplay doesn't compile on musl
Product: LMDB
Version: 0.9.33
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: tools
Assignee: bugs(a)openldap.org
Reporter: bgilbert(a)backtick.net
Target Milestone: ---
With the musl C library (e.g. Alpine Linux) mplay doesn't compile:
gcc -pthread -O2 -g -W -Wall -Wno-unused-parameter -Wbad-function-cast
-Wuninitialized -c mplay.c
mplay.c: In function 'addpid':
mplay.c:490:23: error: assignment of read-only variable 'stdin'
490 | stdin = fdopen(0, "r");
| ^
mplay.c:491:24: error: assignment of read-only variable 'stdout'
491 | stdout = fdopen(1, "w");
| ^
make: *** [Makefile:99: mplay.o] 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=10357
Issue ID: 10357
Summary: Potential buffer underflow in function
config_find_base
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
In function `config_find_base`, we have the code:
```c
char *c = dn->bv_val+dn->bv_len;
for (;*c != ',';c--);
```
In the loop, if the string doesn't contain any commas, `c` will decrement below
`dn->bv_val`, causing buffer underflow when `*c` is accessed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10354
Issue ID: 10354
Summary: Enhancement: Allow tuning of pwdLastSuccess (like
authTimestamp)
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: u.windl(a)ukr.de
Target Milestone: ---
As I understand it, the function of the lastbind overlay were integrated to
slapd core (under different names).
While the overly used attribute authTimestamp, slapd uses attribute
pwdLastSuccess to record the time of successful bind.
So in principle one could activate both at the same time, but the purpose is
unclear...
Anyway the lastbind overlay allows to configure (among others) the
"lastbind-precision", allowing to skip recording of too many successful binds
for a while.
Unfortunately the slapd core does not offer a comparable thing, so (for
example) automated periodic binds (e.g. used for monitoring) may fill a
changelog (delta-syncrepl) over time.
The proposal is to implement some mechanism of rate limiting for the updates of
pwdLastSuccess, or/and allow filtering of DNs that are included/excepted from
this mechanism (so automated periodic system accounts may be excepted).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10169
Issue ID: 10169
Summary: Add support for token only authentication with otp
overlay
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Currently the OTP overlay is password + token. It would be nice to be able to
configure it so it can run in a token only mode, similar to the slapo-totp
overlay in contrib. This would allow us to have a project supported solution
and retire that contrib module.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10308
Issue ID: 10308
Summary: Implement cn=monitor for back-asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Currently back-asyncmeta has no cn=monitor capabilities. It will be useful to
implement some, specifically to monitor targets and target connection states.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10304
Issue ID: 10304
Summary: Unable to remove item from directory as part of
transaction if it is the last item in that directory
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: sophie.elliott(a)arcticlake.com
Target Milestone: ---
I am running my ldap server on Debian 11.3, with the mdb backend, using the
backported openldap version 2.5.13. I am not 100% certain if this is an issue
with OpenLDAP or liblmdb, but I have been running tests in the repo and it
looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself.
I have been performing a transaction, and deleting entries from a directory
during this transaction. This works fine if the item that I am deleting isn't
the last entry in its directory, but when it is I get a MDB_NOTFOUND error on
the commit transaction call and the delete doesn't go through. Here is an
excerpt of the logs when this happens:
```
67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
)
67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624]
67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
) success
67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND:
No matching key/data pair found (-30798)
```
Please let me know if I should submit this issue elsewhere, or if this is
something that has already been fixed in a more recent version. I'm also happy
to provide more details if necessary. Thank you!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10297
Issue ID: 10297
Summary: LDAP initialization does unnecessary resolution of
hostname
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: simon.pichugin(a)gmail.com
Target Milestone: ---
curl --version does try to resolve local hostname, which is usually stored in
$HOSTNAME variable. It seems it does that for no good reason. It does not
matter whether machine hostname is already FQDN or not, it always try it
unconditionally by calling getaddrinfo(3).
Every usage of dnf tries to resolve hostname. That is then supressed by
myhostname on Fedora, which returns non-helping response. Possibly, the
hostname should be fetched from actual network responses.
Seen with:
openldap-2.6.8-5.fc41.x86_64
Reproducible: Always
Steps to Reproduce:
1. dnf install gdb curl
2. gdb --args curl --version
3. (gdb) break getaddrinfo
4. (gdb) run
Actual Results:
getaddrinfo is called with current hostname, stored into ldap_int_hostname
variable. That is used only when ldap client has not configured target server.
But this hostname seems fetched always.
Expected Results:
No network activity happens, unless something is actually requested. This is
not the case.
Suggestion is to make it lazy initialized. It should be tried only when
necessary. This seems to be useful when tlso_session_chkhost in
libraries/libldap/tls_o.c is used. It should initialize hostname only once
conditions to use it happens. There is a fallback anyway. It should query FQDN
only when name_in contains unusable response.
Related: https://github.com/systemd/systemd/issues/34897
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10347
Issue ID: 10347
Summary: Fix a memory leak in function comp_convert_asn_to_ldap
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1076
--> https://bugs.openldap.org/attachment.cgi?id=1076&action=edit
Patch: Fix a memory leak in function comp_convert_asn_to_ldap
In function comp_convert_asn_to_ldap, the bv->bv_val is allocated in 3 places:
case BASICTYPE_BOOLEAN: bv->bv_val = (char*)malloc( 5 );
case BASICTYPE_INTEGER: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE );
case BASICTYPE_ENUMERATED: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE );
When csi->csi_syntax != NULL and csi->csi_syntax->ssyn_pretty != NULL,
bv->bv_val is overwriten with bv->bv_val = prettied.bv_val;, causing porential
memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.