https://bugs.openldap.org/show_bug.cgi?id=10250
Issue ID: 10250
Summary: syncrepl_diff_entry assumes attributes come in the
same order
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: ---
When trying to diff an entry, syncrepl_diff_entry explicitly assumes attribute
come in the same order. That's not always the case and could cause it to report
a spurious rewrite of the attribute.
Normally this is ok, unless the rewrite itself (not) occurring has other
side-effects, when it could cause issues. (e.g. a DB with memberof
inconsistencies being mysteriously repaired in some scenarios, which is how it
was found).
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9225
Bug ID: 9225
Summary: back-mdb: Add support for PREPARE/2-phase commit
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Add support for PREPARE/2-phase commit in back-mdb
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9224
Bug ID: 9224
Summary: Add support for PREPARE/2-phase commit
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
In LMDB, add support for PREPARE/2-phase commits
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=10424
Issue ID: 10424
Summary: When using more than one syncrepl directive on a
single DB, the contextCSN should be stored accordingly
to the replication base
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: elecharny(a)apache.org
Target Milestone: ---
Trying to replicate cn=config but parially, I tried to set many syncrepl
directives so that each oe of them just replicate the single element it is
configured for. Here is an exemple thet replicate the frontend database and
only it:
{0}rid=004
provider=ldaps://openldap1:10636
bindmethod=simple
binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com"
credentials=blah
tls_cacert=/opt/application/openldap/ssl/ca.crt
tls_cert=/opt/application/openldap/ssl/openldap-common.crt
tls_key=/opt/application/openldap/ssl/openldap-common.key
tls_reqcert=demand
tls_protocol_min=3.3
searchbase="olcDatabase={-1}frontend,cn=config"
scope="base"
type=refreshAndPersist
retry="30 +"
timeout=1
schemachecking=off
If I have this single syncrepl directive, all is ok, it replicates the frontend
data and only this entry.
Would I like to replicate, says, 'cn=config' with another syncrepl directive
like:
olcSyncrepl: {0}rid=001
provider=ldaps://openldap1:10636
bindmethod=simple
binddn="cn=syncrepl,ou=accounts,dc=worteks,dc=com"
credentials=blah
tls_cacert=/opt/application/openldap/ssl/ca.crt
tls_cert=/opt/application/openldap/ssl/openldap-common.crt
tls_key=/opt/application/openldap/ssl/openldap-common.key
tls_reqcert=demand
tls_protocol_min=3.3
searchbase="cn=config"
scope="base"
type=refreshAndPersist
retry="30 +"
timeout=1
schemachecking=off
where the search base is different, then suddenly I get some 'CSN too old'
errors, which make totally sense as we only have one single contextCSN stored
in the root entry (cn=config in my use case).
I know I'm really border line here (and the rational is that I want a partial
replication of cn=config because the two servers are a bit different), but I
would suggest that the contextCSN to be stored in the entry associated to the
searchBase, not at the root of the database.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10423
Issue ID: 10423
Summary: It is possible via cn=config to add an entry of one
database type with the object class of another,
causing OpenLDAP to crash
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
This happens specifically because the user by mistake attempts to create a meta
database by specifying the object class for back-ldap. Since these share a lot
of common attributes, schema checks do not fail. As a result, slapd initializes
a meta database (based on olcDatabase value), but attempts to manipulate an
initialized back-ldap database after that, and segfaults.
Like this:
dn: olcDatabase=meta,cn=config
objectClass: olcDatabaseConfig
objectClass: olcLDAPConfig
olcDatabase: meta
olcDbURI: "ldap://example.com"
While it seems this is only possible for the proxy databases, we cannot rely
that schema checks on attributes will fail for other database combinations, who
knows what common attributes can be added or supplied in the future, we we have
to fix this.
The issue is reproducible via slapadd and at runtime with ldapadd.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10383
Issue ID: 10383
Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI
defined after it
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.frickert(a)protonmail.com
Target Milestone: ---
Hi,
We are using slapd-meta to connect an OpenLDAP server to another external LDAP
server and it works well on first configuration.
However, if we want to update any info, e.g. the external LDAP URI, we must
replace the olcDbURI attribute. This means that the ordering of the attributes
change and this attribute is now defined after olcDbIDAssertBind.
Didn't think this would be important, but after this change the "meta"
connection stops working and upon enabling debugging i can see that the
external LDAP server is responding with:
"ldap_bind: Inappropriate authentication (48)
additional info: Anonymous Simple Bind Disabled"
This seems to imply that the olcDbIDAssertBind attribute is being ignored,
likely due to being defined before olcDbURI (my assumption).
Is this intended? If so, what can we do to mitigate this problem?
Do we need to perform a replace on all attributes of the object to ensure
correct ordering, or is there any way to perform an in-place attribute
modification without making it shift its position in the object?
Example:
First configuration (OK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
After URI update (NOK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
The olcDbURI attribute is shifted to the bottom after a modify operation, and
seems to cause these issues.
Best Regards,
David
--
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=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
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: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10439
Issue ID: 10439
Summary: The value of the mc_xcursor pointer in the context of
calling the mdb_xcursor_init1() function
Product: OpenLDAP
Version: 2.6.12
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: mishtitov(a)gmail.com
Target Milestone: ---
Problem occurs in functions `mdb_cursor_first()`, `mdb_cursor_last()` and
`mdb_cursor_set()`.
After having been compared to a NULL value, pointer 'mc->mc_xcursor' is passed
in call to function 'mdb_xcursor_init1()` where it is dereferenced. This might
happen when the node flag `F_DUPDATA` is set, but the database does not have
the `MDB_DUPSORT` flag, leading to `mc->mc_xcursor` being uninitialized.
I think that this is very unlikely to happen, but I haven't found a clear
connection between the `F_DUPDATA` and `MDB_DUPSORT` flags. Please consider
wheter if it's worth adding a NULL check there.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10452
Issue ID: 10452
Summary: Potential NULL dereference in slap_acl_mask()
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: nastentsiya.filimonova(a)gmail.com
Target Milestone: ---
I've noticed potentially inconsistent NULL checks for the op->o_conn field in
function slap_acl_mask (source file openldap-2.6.8/servers/slapd/acl.c).
At first, op->o_conn is explicitly checked for NULL:
if ( op->o_conn && !BER_BVISNULL( &op->o_conn->c_ndn ) ) {
ndn = op->o_conn->c_ndn;
} else {
ndn = op->o_ndn;
}
This suggests that op->o_conn may indeed be NULL in some scenarios.
However, right after that in the same function there are several unconditional
dereferences of op->o_conn without a preceding NULL check, for example:
if ( !op->o_conn->c_listener ) {
continue;
}
if ( !op->o_conn->c_peer_domain.bv_val ) {
continue;
}
if ( !op->o_conn->c_peer_name.bv_val ) {
continue;
}
Could you please clarify whether op->o_conn is guaranteed to be non-NULL
for all possible paths reaching these code sections?
If op->o_conn can indeed be NULL here, these dereferences may lead to
a NULL pointer dereference and would require additional checks.
If op->o_conn is guaranteed to be non-NULL by design, please confirm this (it
would also be useful to document this assumption explicitly).
Thank you.
--
You are receiving this mail because:
You are on the CC list for the issue.