https://bugs.openldap.org/show_bug.cgi?id=10203
Issue ID: 10203
Summary: no pkgconfig file included for liblmdb
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: otto(a)drijf.net
Target Milestone: ---
liblmdb does not ship with a pkgconfig file. More and more build systems rely
on presense of a pkgconfig file, so it would be nice if liblmdb installed
oneone. An example:
prefix=/usr/local
exec_prefix=${prefix}
libdir=${prefix}/lib
includedir=${prefix}/include
Name: lmdb
Description: Lightning memory-mapped database: key-value data store
URL: https://www.symas.com/symas-embedded-database-lmdb
Version: 0.9.32
Libs: -L${libdir} -llmdb
Cflags: -I${includedir}
Thanks.
--
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=10343
Issue ID: 10343
Summary: Potential Memory Leak in function
slap_uuidstr_from_normalized
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: ---
Created attachment 1070
--> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit
Patch: Change 1 to -1.
In function slap_uuidstr_from_normalized, the code allocates a new `struct
berval` with
```c
new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx);
```
and then attempt to allocate `new->bv_val`. If that second allocation fails, it
sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code
only runs when `rc == -1`, so the memory pointed by `new` is never freed,
causing a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10344
Issue ID: 10344
Summary: Potential memory leak in function
firstComponentNormalize and objectClassPretty.
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: ---
Created attachment 1071
--> https://bugs.openldap.org/attachment.cgi?id=1071&action=edit
Patch: Ensure the first argument passed to `ber_dupbv_x` is not `NULL`.
In `firstComponentNormalize`, the code calls `ber_dupbv_x` but ignores its
return value.
```c
ber_dupbv_x(normalized, val, ctx);
```
When `normalized` is `NULL`, `ber_dupbv_x` allocates a new `struct berval` and
returns it; failing to capture that pointer means we lose ownership and leak
the allocation. The same issue arises in `objectClassPretty`. We should follow
the pattern in function `hexNormalize`, which asserts that its `normalized`
argument is non-NULL before use:
```c
assert(normalized != NULL);
```
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10345
Issue ID: 10345
Summary: Potential memory leak in function rbac_create_session
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: ---
In `rbac_create_session`, we have the following code:
```c
if ( rc < 0 ) {
rs->sr_err = LDAP_OTHER;
rs->sr_text = "internal error";
} else {
(void)ber_flatten( ber, &rs->sr_rspdata );
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first
rs->sr_err = LDAP_SUCCESS;
}
ber_free_buf(ber);
done:;
// always put the OID in the response:
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second
```
The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without
freeing the previous string, resulting in a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10339
Issue ID: 10339
Summary: config_add_internal() use-after-free on failed
cn=config mod
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: ---
If overlay startup/callback fails, bconfig.c:5593 uses the value of ca->argv[1]
despite it being freed already. I guess we can just log the entry's DN.
--
You are receiving this mail because:
You are on the CC list for the issue.