https://bugs.openldap.org/show_bug.cgi?id=10071
Issue ID: 10071
Summary: Extra sids in cookie should only be ignored for replay
consideration
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: ---
A consumer's cookie might contain sids that the provider is not aware of. Those
are currently screened out. This is appropriate for initial checks whether/how
to allow the operation to go ahead but might be needed for content
determination in refresh/persist. As such the cookie should be retained rather
than edited in place.
I don't have the logs from a failed test at hand but will post the
analysis/logs if I find them again.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10168
Issue ID: 10168
Summary: olcdbindex doesn't cleanup cleanly
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 you run the following modify against slapd (notice the olcDbMultival data is
wrong), slapd aborts in mdb_cf_cleanup->mdb_attr_dbs_open when cleaning up the
olcDbIndex changes:
dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: member eq
olcDbIndex: memberof eq
-
add: olcDbMultival
olcDbMultival: member,memberOf 5,15
-
--
You are receiving this mail because:
You are on the CC list for the issue.
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=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|2.6.8 |2.6.9
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10202
Issue ID: 10202
Summary: slapd fails to start if compiled with
--enable-overlays=yes
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: nivanova(a)symas.com
Target Milestone: ---
Statically compiling all overlays produces the following error at slapd
startup:
66192034.2adbbeb4 0x73de9d4547c0 register_at: AttributeType "(
1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to'
SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE
dSAOperation NO-USER-MODIFICATION X-ORIGIN 'iPlanet Delegated Administrator'
)": Duplicate attributeType, 1.2.840.113556.1.2.102
66192034.2adc2a97 0x73de9d4547c0 overlay_register("nestgroup"): name already in
use.
66192034.2adc44ed 0x73de9d4547c0 nestgroup overlay setup failed, err -1
66192034.2adc5016 0x73de9d4547c0 slapd: overlay_init failed
66192034.2adc5e14 0x73de9d4547c0 slapd destroy: freeing system resources.
66192034.2adefbff 0x73de9d4547c0 slapd stopped.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10201
Issue ID: 10201
Summary: Update autotools to 2.71
Product: OpenLDAP
Version: 2.6.7
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Update to newer autotools to work with current configure.ac requirements
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10199
Issue ID: 10199
Summary: pwdPolicySubentry set at user level
Product: OpenLDAP
Version: 2.4.59
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: kiruthiga_rajangam(a)comcast.com
Target Milestone: ---
I have three distinct password policies, and I aim to apply one of them to a
user group so that members of the group inherit the policy.
However, when I set the pwdPolicySubentry attribute of the group, the members
do not seem to inherit the policy automatically.
Instead, each member must be individually assigned the pwdPolicySubentry
attribute for the policy to take effect.
Is there something I'm overlooking in this process?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10200
Issue ID: 10200
Summary: Can pcacheTemplate support '!' operator
Product: OpenLDAP
Version: 2.5.16
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: shaosong.li(a)salesforce.com
Target Milestone: ---
Hi,
I am using Openldap V2.5.17 and pcache engine for cache. After multiple rounds
of testing, I found the '!" is not supported in the pcacheTemplate, such as
below, which is used for filter from ldap query (!(uidNumber=0)).
pcacheTemplate (!(uidNumber=)) 0 6000 300 0 0
While checking the source code, i don't see the '!' operator supported,
however, I do see '&' and '|' in the source code.
https://git.openldap.org/openldap/openldap/-/blob/OPENLDAP_REL_ENG_2_5/serv…
Thanks,
--
You are receiving this mail because:
You are on the CC list for the issue.