https://bugs.openldap.org/show_bug.cgi?id=10149
Issue ID: 10149
Summary: [PATCH] Allow certificates and keys to be read from
URIs.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: minfrin(a)sharp.fm
Target Milestone: ---
Add the LDAP_OPT_X_TLS_URIS and LDAP_OPT_X_TLS_CACERTURIS
options to allow certificates and keys to be set using OpenSSL
provider URIs.
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Graham Leggett minfrin(a)sharp.fm. I have not assigned rights and/or
interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2023 Graham Leggett
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10302
Issue ID: 10302
Summary: Double free of idcursor
Product: OpenLDAP
Version: 2.6.6
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: simon.rupf(a)lzlabs.com
Target Milestone: ---
Created attachment 1050
--> https://bugs.openldap.org/attachment.cgi?id=1050&action=edit
proposed patch, which was created from current master, but also applies to
2.6.6
While switching from Oracle Linux (a RHEL clone) 8 to 9 one of our larger LDAP
samples started causing a double free error at the end of the slapadd run.
While I can't share the LDIF in question and it didn't consistently cause the
issue, only every 5-6 times it ran, I could ran gdb and valgrind on it and
suggest the attached patch that resolves that error to re-occur. I validated
the patch still applies to the current master branch of openldap, as well as to
2.6.6 on EL9 where we encountered this.
The error originally observed was this (commands being run as ldap user):
[...]
rm -r /var/lib/ldap
mkdir /var/lib/ldap
slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
-#################### 100.00% eta none elapsed 03s spd 4.2 M/s
Closing DB...double free or corruption (!prev)
Under valgrind, the following trace could be observed:
valgrind --vgdb=full --leak-check=full --show-leak-kinds=all
--track-origins=yes slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502== Memcheck, a memory error detector
==502== Copyright (C) 2002-2024, and GNU GPL'd, by Julian Seward et al.
==502== Using Valgrind-3.23.0 and LibVEX; rerun with -h for copyright info
==502== Command: slapadd -l /tmp/lz_vault_convert_add.ldif -q -w -n 2
==502==
PROXIED attributeDescription "LZVAULTPROFILECOUNT" inserted.
PROXIED attributeDescription "LZVAULTGLOBALPROFILECOUNT" inserted.
==502== Invalid read of size 8
==502== at 0x1E65A9: mdb_cursor_close (mdb.c:7764)
==502== by 0x1F71B8: UnknownInlinedFun (tools.c:202)
==502== by 0x1F71B8: mdb_tool_entry_close (tools.c:152)
==502== by 0x1D8291: slapadd (slapadd.c:511)
==502== by 0x1348C6: main (main.c:540)
==502== Address 0x188c8af8 is 8 bytes inside a block of size 392 free'd
==502== at 0x4847B4C: free (vg_replace_malloc.c:989)
==502== by 0x22CEFE: mdb_cursors_close.isra.0 (mdb.c:2638)
==502== by 0x1EBAAE: mdb_txn_commit (mdb.c:3640)
==502== by 0x1F75E2: mdb_tool_entry_modify (tools.c:1066)
==502== by 0x1D9AF9: slap_tool_update_ctxcsn.part.0 (slapcommon.c:1069)
==502== by 0x1D8440: UnknownInlinedFun (slapcommon.c:962)
==502== by 0x1D8440: slapadd (slapadd.c:502)
==502== by 0x1348C6: main (main.c:540)
==502== Block was alloc'd at
==502== at 0x484482F: malloc (vg_replace_malloc.c:446)
==502== by 0x1E8699: mdb_cursor_open (mdb.c:7690)
==502== by 0x1F8C45: mdb_tool_entry_put (tools.c:707)
==502== by 0x1D8150: slapadd (slapadd.c:453)
==502== by 0x1348C6: main (main.c:540)
[...]
Please advise if I can provide any further diagnostics, while I can still
relatively easily reproduce the issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10296
Issue ID: 10296
Summary: Force a Mac OS full flush
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Created attachment 1045
--> https://bugs.openldap.org/attachment.cgi?id=1045&action=edit
Use a F_FULLFSYNC fcntl when committing on Mac OS
Hello Howard and Happy New Year,
As discussed in this issue [1], the LMDB durability is incorrect when
committing. I propose the following patch that uses fcntl with the F_FULLFSYNC
flag. The fcntl documentation is on this page [2].
Note that I kept the calls to msync/fsync for simplicity and because they don't
cost much but feel free to skip them on Mac OS.
Have a nice day,
kero
[1]: https://github.com/cberner/redb/pull/928#issuecomment-2567032808
[2]:
https://developer.apple.com/library/archive/documentation/System/Conceptual…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10300
Issue ID: 10300
Summary: Add detailed instructions for MRs to "Guidelines for
Contributing" page
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
The current page covers submitting patches but doesn't adequately cover
creating merge requests. This provides a barrier for new developers.
In addition to clarifying when a change should be submitted with a patch or
merge request, it could provide a set of steps including creating a fork,
branch, squash, fixup, naming conventions and other info that would be lost on
a new contributor.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9245
Bug ID: 9245
Summary: devel/programming needs rewrite
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The information on the devel/programming web page is at least a decade out of
date and needs a complete overhaul.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10294
Issue ID: 10294
Summary: Overlay seems to load before schema in folder
configuration mode
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: pduvax(a)gmail.com
Target Milestone: ---
In the folder configuration (vs slapd.conf file), the modules seem to be loaded
before schema folders files.
This makes troubles with memberOf attributeType which is created by the dynlist
overlay if missing (cf. the base function "dynlist_initialize" which starts by
doing this). As the schema files are not yet loaded, it creates systematically
the attributes which then prohibits the load of msuser.ldif schema without
raising the error "Duplicate attributeType".
I found a workaround by naming the entry of the dynlist overlay olcModuleList
cn=z-module{X} while z is alphanumerically after cn=schema. But as it is
hazardous, I think that the best way is to load modules after the schema by the
code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10301
Issue ID: 10301
Summary: Use assertion control in lastbind chaining
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: ---
Take a setup with a bunch of consumers tracking lastbind information and
replicating this back from the provider. If a client sends a lot of successful
binds to it in a very short window, the changes might not have a chance to
replicate down so each of these binds has to trigger a new modification to be
forwarded.
This results in a lot of DB churn and replication traffic that is actually
meaningless (the pwdLastChange values before and after each of the mods will be
the same).
We probably can't avoid having to send something, but the change we send could
have an assertion control attached that lets the provider skip it if
pwdLastChange>=new_value, saving on all of the additional processing (and
additional useless replication traffic).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10298
Issue ID: 10298
Summary: cannot find DN in memberOf attribute when dynlist
overlay contains multiple memberOf definitions
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: jan.pekar(a)imatic.cz
Target Milestone: ---
I'm using dynlist to define multiple static objectClasses (static-oc) to be
searched for member attributes and added to memberOf attribute.
My configuration is in cn=config, so I defined it using multiple olcDlAttrSet
attributes
groupOfURLs memberURL member+memberOf@groupOfMembers*
groupOfURLs memberURL member+memberOf@groupOfNames*
I noticed, that memberOf attribute contains users from both groups
(groupOfMembers and groupOfNames) but I can use search operation to only first
defined configuration (in above example groupOfMembers) and user membership
from groupOfNames groups is not found.
Maybe it must be defined in one line but I was not able to find proper syntax.
Maybe attribute must be mapped somehow but when it works for first definition,
should be working for next one so it is bug?
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=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|INVALID |---
Status|VERIFIED |CONFIRMED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8988
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|slapd |liblmdb
Version|2.4.47 |0.9.33
Assignee|bugs(a)openldap.org |hyc(a)openldap.org
Target Milestone|--- |0.9.34
Product|OpenLDAP |LMDB
--
You are receiving this mail because:
You are on the CC list for the issue.