https://bugs.openldap.org/show_bug.cgi?id=10455
Issue ID: 10455
Summary: Allow handling of empty group in
memberof_saveMember_cb()
Product: OpenLDAP
Version: 2.6.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: roger.j.meier(a)gmx.ch
Target Milestone: ---
Created attachment 1117
--> https://bugs.openldap.org/attachment.cgi?id=1117&action=edit
Protect e_attrs with a NULL pointer test instead of an assert() to allow empty
groups
In slapd/overlays/memberof.c, the callback
memberof_saveMember_cb()
uses two assert statements for the sr_entry and its e_attrs pointer in
sequence. This makes the service abort on an empty group. If the use of
rs->sr_entry->e_attrs is just protected by a test of the e_attrs pointer, the
code does not abort and allows empty groups.
Please consider to add this patch to the official source.
It was now several month in production and did not lead to unexpected results.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10401
Issue ID: 10401
Summary: liblber: undefined shift of -1 in ber_decode_int()
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Report from curl project. Full info here
https://gist.github.com/bagder/44a0711fa1989951f2a2395fe992530e
Relevant stack trace:
[Environment]
UBSAN_OPTIONS=exitcode=77:print_stacktrace=1:silence_unsigned_overflow=1
+----------------------------------------Release Build
Stacktrace----------------------------------------+
Command: /mnt/scratch0/clusterfuzz/resources/platform/linux/unshare -c
-n
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap
-rss_limit_mb=2560 -timeout=60 -runs=100
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c
Time ran: 0.14911556243896484
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 1947994398
INFO: Loaded 1 modules (211579 inline 8-bit counters): 211579
[0x559e5bb87a40, 0x559e5bbbb4bb),
INFO: Loaded 1 PC tables (211579 PCs): 211579
[0x559e5bbbb4c0,0x559e5bef5c70),
/mnt/scratch0/clusterfuzz/bot/builds/clusterfuzz-builds_curl_4cc8f5a06444eef5b5b6682762bec8608d45b81b/revisions/curl_fuzzer_ldap:
Running 1 inputs 100 time(s) each.
Running:
/mnt/scratch0/clusterfuzz/bot/inputs/fuzzer-testcases/crash-1364ab2dfa120fe4460381a08f4f158f8d47a30c
decode.c:316:21: runtime error: left shift of negative value -1
#0 0x559e5b730e08 in ber_decode_int
curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:316:21
#1 0x559e5b730c5d in ber_get_int
curl_fuzzer/build/openldap/src/openldap_external/libraries/liblber/decode.c:293:9
#2 0x559e5b6e60f3 in try_read1msg
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:592:7
#3 0x559e5b6e60f3 in wait4msg
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:393:12
#4 0x559e5b6e60f3 in ldap_result
curl_fuzzer/build/openldap/src/openldap_external/libraries/libldap/result.c:120:7
#5 0x559e5af804d6 in oldap_connecting curl/lib/openldap.c:826:10
#6 0x559e5aead984 in protocol_connecting curl/lib/multi.c:1794:14
#7 0x559e5aead984 in multi_runsingle curl/lib/multi.c:2510:16
#8 0x559e5aeacd4f in curl_multi_perform curl/lib/multi.c:2791:18
#9 0x559e5ae7fb38 in fuzz_handle_transfer(fuzz_data*)
curl_fuzzer/curl_fuzzer.cc:419:5
#10 0x559e5ae7eff0 in LLVMFuzzerTestOneInput
curl_fuzzer/curl_fuzzer.cc:97:3
#11 0x559e5add608d in fuzzer::Fuzzer::ExecuteCallback(unsigned char
const*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerLoop.cpp:619:13
#12 0x559e5adc0e02 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char
const*, unsigned long)
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:329:6
#13 0x559e5adc6cd0 in fuzzer::FuzzerDriver(int*, char***, int
(*)(unsigned char const*, unsigned long))
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerDriver.cpp:865:9
#14 0x559e5adf2802 in main
/src/llvm-project/compiler-rt/lib/fuzzer/FuzzerMain.cpp:20:10
#15 0x7c4beb5b7082 in __libc_start_main
/build/glibc-LcI20x/glibc-2.31/csu/libc-start.c:308:16
#16 0x559e5adb9eed in _start
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior decode.c:316:21
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10286
Issue ID: 10286
Summary: ldap_pvt_gettime may result in "not new enough csn"
problems in multi-thread case.
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 971748261(a)qq.com
Target Milestone: ---
Created attachment 1041
--> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit
the log of adding two entry which shows the time sequence.
I used openldap as krb5's database, and openldap was deploymented in
mirrormode.
I tried to add kerberos principals via kadmin.local -q "addprinc -randkey
principal.
slapd log showed that the entry of kadmin/admin was added earlier than the
entry of ossuser. But the csn of kadmin/admin was greater than ossuser.
In this case, when the two entry began to sync to the other slapd server,
ossuser was ignored because of "csn not new enough"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10269
Issue ID: 10269
Summary: slap-constraint: Refactor to use a sorted array
Product: OpenLDAP
Version: 2.6.8
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: ---
As noted in the comments for slapo-constraint:
/*
* Linked list of attribute constraints which we should enforce.
* This is probably a sub optimal structure - some form of sorted
* array would be better if the number of attributes constrained is
* likely to be much bigger than 4 or 5. We stick with a list for
* the moment.
*/
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10277
Issue ID: 10277
Summary: How to deal with desync between cn=config and
back-ldif DNs
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 someone deletes a cn=config entry offline (or through bugs in cn=config,
they exist, will file as I isolate), the X-ORDERED RDNs will not be contiguous.
cn=config papers over this internally at a cost of never being able to modify
the entries affected.
Right now the only remedy is slapcat+slapadd of the whole config DB, is that
the best we can do? When we detect this (doesn't always happen), should we fix
the on-disk copy on startup?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9782
Issue ID: 9782
Summary: regression test its8752 failure
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 a contextCSN update (new cookie) goes from server A through server B to
server C, server C will use that CSN to update entryCSN as well (which neither
A nor B did). This fails the initial replication check.
The issue has likely existed since deltasync was made possible, a version of
this is confirmed at least in 2.4.60 onwards to current master. In principle,
it is related to concerns raised in ITS#9580.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10217
Issue ID: 10217
Summary: autoca should support more key types
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Currently autoca only creates certificates using RSA keypairs. It should at
least have an option to use Elliptic Curve keypairs. It probably also needs
options to specify other signature algorithms other than the default of SHA256.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10257
Issue ID: 10257
Summary: Documentation assessment
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Created attachment 1031
--> https://bugs.openldap.org/attachment.cgi?id=1031&action=edit
Admin guide assessment
Last month I commissioned a tech writer to review the current 2.6 Admin Guide
to see what needs to be worked on before the 2.7 release. I'm attaching the
report here so we can reference it. Should have distributed it sooner but Life
got in the way.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10403
Issue ID: 10403
Summary: Add a configuration directive that uses the OpenSSL
CONF API to allow openldap config files to set any
configuration supported by that API, and to get new
OpenSSL configuration capabilities through that API
with no changes in openldap.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: stephen.wall(a)redcom.com
Target Milestone: ---
Created attachment 1090
--> https://bugs.openldap.org/attachment.cgi?id=1090&action=edit
Add a configuration directive that uses the OpenSSL CONF API to allow openldap
config files to set any configuration supported by that API, and to get new
OpenSSL configuration capabilities through th
I am submitting a patch to create a new directive for OpenLDAP config files
that uses the OpenSSL SSL_CONF API to allow configuration of any aspect of
OpenSSL that the API supports without adding specific directives to OpenLDAP
for them. When OpenSSL extends that API, all versions of OpenLDAP with thie
patch will also support those extensions with no additional code.
--
You are receiving this mail because:
You are on the CC list for the issue.