https://bugs.openldap.org/show_bug.cgi?id=10306
Issue ID: 10306
Summary: epoll, kqueue etc. are not used when cross compiling
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hi(a)alyssa.is
Target Milestone: ---
OpenLDAP's build system relies on running test programs to see whether epoll or
kqueue are available, after checking the headers are available. When cross
compiling, test programs can't be run, and even if they could, they wouldn't
produce useful results because they'd be testing the build machine. Running
test programs like this isn't even a great idea for native builds, because the
package is still quite likely to end up running on a different machine than it
was built for — think about distro packages.
This means that cross-compiled OpenLDAP ends up using select, even though it
could almost certainly use epoll or kqueue.
The best thing to do for this sort of thing is to check at runtime whether the
epoll/kqueue/whatever is available, and fall back if not, but this would
probably be hard to implement in OpenLDAP. Other, easier, things that could be
done to improve the situation would be:
• Assume that epoll/kqueue are available if the headers are. It's very
unlikely nowadays that a system with the headers won't actually have the API
available.
• If the AC_RUN_IFELSE checks are staying, make sure that they're all
overridabel with configure flags or at least AC_CACHE_CHECK.
There are also uses of AC_RUN_IFELSE for pthreads, which presumably have the
same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10416
Issue ID: 10416
Summary: Allow setting fractional timeouts in ldaprc
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: enhancement
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Created attachment 1099
--> https://bugs.openldap.org/attachment.cgi?id=1099&action=edit
Patch to libldap init.c
Currently the ldap.conf parser only accepts integer seconds, even though the
internal variable also accommodates microseconds. A simple patch is attached.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10506
Issue ID: 10506
Summary: Remove back-sql from OpenLDAP 2.7
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
back-sql was deprecated with OpenLDAP 2.6. Remove it from OpenLDAP 2.7
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8901
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10460
Issue ID: 10460
Summary: Stray uses of fprintf in libldap
Product: OpenLDAP
Version: 2.6.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: minor
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
avl.c, cyrus.c, error.c, ldap_sync.c, ldifutil.c contain uses of
`fprintf(stderr,...)` which should probably use Debug instead.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10310
Issue ID: 10310
Summary: Update pbkdf2 overlay so iterations can be
configurable
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The pbkdf2 password hashing contrib overlay has the number of iterations hard
coded at 10,000. It would be helpful to update the module to allow this to be
configurable instead, as is done with other password hashing modules.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9577
Issue ID: 9577
Summary: slapd -V should be deprecated
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: smckinney(a)symas.com
Target Milestone: ---
Sometimes a user's (present one included) ignorance gets them in trouble
unnecessarily. The -V option is an example...
Normally, when one wants to determine the version of a process, they use -V, or
perhaps -v. With slapd, the daemon actually continues to run, which can have
negative consequences.
The doc clearly states that -VV is probably what the user wants, but is
counter-intutive. Who RTFM's before checking the version?
-V print version info (-VV exit afterwards, -VVV print
info about static overlays and backends)
I propose we eliminate the option to allow slapd to continue running after
displaying the version. Perhaps we eliminate the -V option entirely, or just
make it work the same as -VV.
--
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=10278
Issue ID: 10278
Summary: Move away from python-ldap0 in the test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
While python-ldap0 has a superior API, it seems the module is no longer
receiving any development. We should move our python test suite over to another
module that can be supported long-term.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9367
Issue ID: 9367
Summary: back-mdb: encryption support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Need to add encryption support to the back-mdb backend, depends on issue#9364
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6151
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6825
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
Resolution|TEST |FIXED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=8890
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10458
Issue ID: 10458
Summary: improve handling of large entry modifications
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 modifying a huge entry (e.g. a super-large group with countless members), we
(back-mdb) spends about 50% of time on memmove() in attr_dup2 just copying the
data around. We don't need this, this e_attrs doesn't outlive the mdb_modify
that transitively calls it nor do we write into the data themselves.
We should be able to tell attrs_dup that it can reuse parts of the original
attributes and set `SLAP_ATTR_DONT_FREE_DATA` on the resulting attributes if
the caller claims it will take care of the lifetimes accordingly, including any
new values it puts in.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6462
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|TEST |FIXED
Status|RESOLVED |VERIFIED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9796
Issue ID: 9796
Summary: Deprecate GnuTLS support
Product: OpenLDAP
Version: 2.6.1
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Support for GnuTLS was added specifically for the Debian (and thus Ubuntu) due
to the license objections at the time that the Debian project had for the
OpenSSL license.
Since that time, Debian has reclassified OpenSSL as a core library and the
OpenSSL project has resolved the original complaint by licensing OpenSSL 3 and
later under the Apache License v2.
Thus there is no longer a reason to maintain support for GnuTLS and given the
long standing concerns over the security and quality of the GnuTLS bridge in
addition to the extra cost of maintaining that code, it should be marked as
deprecated and removed in a future release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10338
Issue ID: 10338
Summary: constraint overlay rejects empty modifications
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If configured even with no rules, a modification with a NULL op->orm_modlist is
rejected, despite not being able to break any constraints, e.g.:
dn: cn=example
changetype: modify
# no modifications attached
This should at least be configurable.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10488
Issue ID: 10488
Summary: Multiple out-of-bounds reads in servers/slapd/result.c
v2ref() function
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: wangxiaomeng(a)kylinos.cn
Target Milestone: ---
Created attachment 1142
--> https://bugs.openldap.org/attachment.cgi?id=1142&action=edit
Fix two out-of-bounds reads in servers/slapd/result.c v2ref() function
The v2ref() function in servers/slapd/result.c is responsible for converting
LDAPv3 referrals to an LDAPv2-compatible string format. Two separate
out-of-bounds read vulnerabilities exist in this function, both caused by
insufficient checks for zero-length data before accessing the last character of
the data buffer.
Vulnerability 1: Out-of-bounds read in text buffer handling
Location: servers/slapd/result.c, line 94 (within the v2ref() function):
Vulnerable Code:
if ( text != NULL ) {
len = strlen( text );
if (text[len-1] != '\n') {
i = 1;
}
}
When the 'text' parameter is non-NULL but points to an empty string (""),
strlen(text) returns 0. Accessing text[len-1] (i.e., text[-1]) results in an
out-of-bounds read of one byte before the start of the 'text' buffer.
Vulnerability 2: Out-of-bounds read in BerValue referral handling
Location: servers/slapd/result.c, line 115 (within the v2ref() function)
Vulnerable Code:
len += ref[i].bv_len;
if (ref[i].bv_val[ref[i].bv_len-1] != '/') {
++len;
}
When ref[i].bv_val is non-NULL but ref[i].bv_len is 0 (a valid state per LDAP
BerValue semantics, representing an empty string), accessing
ref[i].bv_val[ref[i].bv_len-1] (i.e., ref[i].bv_val[-1]) results in an
out-of-bounds read of one byte before the start of the ref[i].bv_val buffer.
Fix
Add checks for zero-length data before accessing the last character of the
respective buffers. The fix addresses both vulnerabilities with minimal,
targeted changes that preserve the original functionality.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10497
Issue ID: 10497
Summary: o_ctrlflags usage confused
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: ---
There is widespread confusion about what is stored in o_ctrlflags (and
retrieved with get_<control> macros.)
Some code is spot on e.g., get_pagedresults() and checks for
SLAP_CONTROL_NON/CRITICAL/IGNORED as it should, most of them expect 0/1
(assert, manageDSAiT, ...)
We could correct all the get_* tests to check for > IGNORED or just add a has_
variant if we want to keep the code simple for those that don't need to bother.
And we want to fix autogroup to set o.o_permissive_modify correctly.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10456
Issue ID: 10456
Summary: Record time it took to run purge task
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
accesslog could report a summary at the end of the purge saying how long it
took and how many entries were (or would have been if shutting down) removed in
that run. Thinking SYNC level as that's where most accesslog's messages go
already.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9493
Issue ID: 9493
Summary: slapo-accesslog handling of deletion of multi-valued
configuration attributes removes wrong value from list
Product: OpenLDAP
Version: 2.4.57
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: svella(a)technologist.com
Target Milestone: ---
I observed this in the debugger while working on a small feature addition to
slapo-accesslog.
log_cf_gen(), when handling the initial configuration of oldAccessLogOldAttr
(accesslog.c:989), linked list li_oldattrs is being built by inserting each
value in order at the head of the list, resulting in the list being in reverse
order. But when handling LDAP_MOD_DELETE of same attribute (accesslog.c:989),
it is using the index of the removed value (valx) to find and removed the entry
in the linked list, but it's counting from the head of li_oldattrs and not the
tail, resulting in the wrong item being removed from the list unless counting
from the head or the tail happens find the same item.
(Line numbers refer to commit 6c469f07935e351e349bf38fc223dab704c51a76)
Handling of oldAccessLogBase appears to have the same problem, and a cursory
glance through the source of other overlays reveals a similar pattern, and I'm
guessing the same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |VERIFIED
Resolution|TEST |FIXED
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9556
Issue ID: 9556
Summary: slapd-config should return invalidAttributeSyntax if
parsing schema description fails
Product: OpenLDAP
Version: 2.5.4
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
I'm currently testing error handling and interacting with LDAP clients (e.g. my
web2ldap).
Sending an invalid attribute type description results in an error (as expected)
returned by slapd-config:
RESULT tag=103 err=80 qtime=0.000032 etime=0.001271 text=olcAttributeTypes:
Unexpected token before SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 )
But result code other(80) seems not very useful. It's too unspecific to decide
on specific error handling.
It would be much more useful if slapd-config returns invalidAttributeSyntax(21)
in this case.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9959
Issue ID: 9959
Summary: Expose the lloadd connection endpoints in cn=monitor
for identification
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: lloadd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
ITS#9600 introduces a way to operate on lloadd connections, however it is
impossible to identify which socket this actually corresponds to. While we're
at it, might also expose the current bound identity there.
--
You are receiving this mail because:
You are on the CC list for the issue.