https://bugs.openldap.org/show_bug.cgi?id=10191
Issue ID: 10191
Summary: backend searches should respond to pause requests
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
A long running search will cause mods to cn=config to wait a long time. Search
ops should periodically check for threadpool pause requests.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10162
Issue ID: 10162
Summary: Fix for binary attributes data corruption in back-sql
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: dex.tracers(a)gmail.com
Target Milestone: ---
Created attachment 1006
--> https://bugs.openldap.org/attachment.cgi?id=1006&action=edit
Fix for binary attributes corruption on backed-sql
I've configured slapd to use back-sql (mariadb through odbc) and observed
issues with the BINARY data retrievals from the database. The length of the
attributes was properly reported, but the correct data inside was always 16384
bytes and after that point - some junk (usually filled-up with AAAAAAAA and
some other attributes data from memory).
During the debugging - I've noticed that:
- The MAX_ATTR_LEN (16384 bytes) is used to set the length of the data for
BINARY columns when SQLBindCol is done inside of the
"backsql_BindRowAsStrings_x" function
- After SQLFetch is done - data in row->cols[i] is fetched up to the specified
MAX_ATTR_LEN
- After SQLFetch is done - the correct data size (greater than MAX_ATTR_LEN) is
represented inside of the row->value_len
I'm assuming that slapd allocates the pointer in memory (row->cols[i]), fills
it with the specified amount of data (MAX_ATTR_LEN), but when forming the
actual attribute data - uses the length from row->value_len and so everything
from 16384 bytes position till row->value_len is just a junk from the memory
(uninitialized, leftovers, data from other variables).
After an investigation, I've find-out that:
- for BINARY or variable length fields - SQLGetData should be used
- SQLGetData supports chunked mode (if length is unknown) or full-read mode if
the length is known
- it could be used in pair with SQLBindCol after SQLFetch (!)
Since we have the correct data length inside of row->value_len, I've just added
the code to the backsql_get_attr_vals() function to overwrite the corrupted
data with the correct data by issuing SQLGetData request. And it worked -
binary data was properly retrieved and reported over LDAP!
My current concerns / help needed - I'm not very familiar with the memory
allocation/deallocation mechanisms, so I'm afraid that mentioned change can
lead to memory corruption (so far not observed).
Please review attached patch (testing was done on OPENLDAP_REL_ENG_2_5_13, and
applied on the master branch for easier review/application).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10194
Issue ID: 10194
Summary: Does LMDB support zero length keys?
Product: LMDB
Version: 0.9.29
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: roger.marsh(a)btinternet.com
Target Milestone: ---
I suspect the answer is 'No' but do not see a definitive statement.
I followed the Python code and documentation trail below, but decided to ask
here when I concluded I could not decide.
Some Python code was adapted from berkeleydb to lmdb and gave an exception for
a
cursor.set_range_dup(b'', <some value>) call. Reading the lmdb/cffi.py code in
site-packages prompted me to try cursor.set_range(b''), which seemed reasonable
given that is what is done for berkeleydb, and it worked.
However cursor.put(b'', <some value>) gave an exception quoting "mdb_put:
MDB_BAD_VALSIZE ...".
The documentation for the Python interface to LMDB at lmdb.readthedocs.io/
states behaviour for the empty bytestring for set_key(), set_key_dup(), and
set_range(); but not for set_range_dup() or put(). Only set_key() and
set_key_dup() describe empty bytestring as an error.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7298
--- Comment #6 from Howard Chu <hyc(a)openldap.org> ---
"No data for this control" means the data portion should not be sent at all.
Setting bv_len and bv_val is just the quirk of how their API is designed. If we
accept their published spec at face value, then their C# SDK implementation is
wrong, because it is sending zero length data instead of "no data". You should
submit a ticket to Microsoft to resolve this by either fixing their doc or
fixing their SDK, whichever the case may be. The current OpenLDAP behavior
conforms to their official spec so there is no OpenLDAP bug here.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7298
--- Comment #5 from lesignor(a)cirad.fr ---
In the Microsoft documentation
(https://learn.microsoft.com/en-us/previous-versions/windows/desktop/ldap/ld…),
they write :
ldctl_value
No data for this control. In the berval structure, set bv_len to zero and
bv_val to NULL.
As they said set bv_len to zero, I guess some developer choose to send 04 00 to
set the length to 0, and other consider to remove all fields.
The ldap client, I use, is a dotnet client. I think it uses the c# sdk from
Microsoft.
Would it be possible to accept both implementation (null or empty) ?
It will be a great help to migrate to openldap 2.6.x.
Thanks
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10192
Issue ID: 10192
Summary: otp.c overlay - HOTP wrongly numbers gneration
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: michal.pura(a)gmail.com
Target Milestone: ---
Hello, I am trying to use otp.c overlay but seems that numbers are not properly
generated.
In my case I have random secret like 'aaaabbbbccccdddd' and according to what
Google Authenticator and https://www.verifyr.com/en/otp/check#hotp is
generating we should have the following HOTP codes for above secret:
1 - 229789
2 - 801677
3 - 630108
4 - 214543
5 - 916392
6 - 346078
7 - 701644
8 - 865071
9 - 431248
10 - 355053
but, otp.c module is returning the following numbers:
1 - 441008
2 - 465617
3 - 669281
4 - 042697
5 - 461210
6 - 620979
7 - 700859
8 - 573924
9 - 805067
10 - 135880
The secret is properly generated and used in the code. I've checked it under
debugger. The hash algorithm is defined as 1.2.840.113549.2.7 ->
HMAC-WITH-SHA1. What is wrong?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7400
--- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• ae1c8f18
by Howard Chu at 2024-02-20T15:55:37+00:00
ITS#7400 slapo-memberof: delete note about deprecation
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7400
--- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26:
• f30def77
by Howard Chu at 2024-03-26T16:38:10+00:00
ITS#7400 slapo-memberof: delete note about deprecation
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10082
Issue ID: 10082
Summary: More dynlist eval tweaks
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
When the memberOf attribute is a user attribute instead of operational, it will
be expanded on any search for (all user attributes). If the search is filtering
on objectclasses that don't contain this attribute, that's wasted work. Check
for a matching objectclass in the filter before doing that.
--
You are receiving this mail because:
You are on the CC list for the issue.