https://bugs.openldap.org/show_bug.cgi?id=10367
Issue ID: 10367
Summary: Article for 'Asynchronous Metadirectory backend' seems
to be typo.
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: truth_jp_4133(a)yahoo.co.jp
Target Milestone: ---
In the table of '6.2.2.1. backend <type>'section on this
page(https://www.openldap.org/doc/admin26/slapdconfig.html), the description
about asyncmet is 'a Asynchronous Metadirectory backend', but I think that this
is 'an Asynchronous Metadirectory backend'.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10360
Issue ID: 10360
Summary: delta-sync can apply old mods
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
This might be related to #10358, but not sure.
In delta MPR, if an older mod is received on an entry after a newer mod has
already been applied by a local user, the older mod is applied and the newer
mod is lost.
The incoming replication ops are checked for freshness by check_csn_age() but
that only checks the incoming cookieCSN against contextCSNs of the same SID.
I.e., that check only prevents duplicate mods being replicated multiple times
from the same remote provider. If check_csn_age() passes, then
syncrepl_message_to_op() is invoked which just applies the mod. It doesn't
check the mod or cookieCSN against the entry's current entryCSN.
The code in syncrepl_op_mod() performs the checks we need. The code just needs
to be pulled into a new function so it can be used in both places.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10390
Issue ID: 10390
Summary: ldif_parse_line2 calculates an incorrect length of the
attribute type
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: nivanova(a)symas.com
Target Milestone: ---
When parsing a line containing an attribute name and a value, e.g "carLicence
: 12344", ldif_parse_line2 calculates the type length incorrectly. It is not
clear if this affects any existing code or tools at the moment, but should be
fixed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10349
Issue ID: 10349
Summary: Free ch_calloc-allocated memory in error paths
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1078
--> https://bugs.openldap.org/attachment.cgi?id=1078&action=edit
Free ch_calloc-allocated memory in error paths
1. In aa_operational, bv_allowed and bv_effective are allocated via ch_calloc.
If ja == 0 or je == 0, these memory objects are never freed and do not escape
the function, causing potential memory leak.
2. In memberof_db_init, the memory allocated by ch_calloc isn’t released on
error paths, leading to another potential leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10398
Issue ID: 10398
Summary: memberof and refint clash on subtree renames
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: hyc(a)openldap.org
Target Milestone: ---
If a group and its members are under a subtree that got renamed, refint will
trigger, and try to update all the relevant DNs. When it processes the group
entry, it will issue Modifies to update the DNs of the group's members. The
memberof overlay will see these modifies and start trying to update the
corresponding memberof values but will only succeed halfway.
It will try to delete the old memberof value from the old member DN's entry,
which fails because the subtree has renamed all the entries. Then it will try
to add the new memberof value to the new member DN's entry, which succeeds.
Then eventually refint will try to process the member's. It will try to delete
the old memberof value from the new entry, and add the new memberof value to
the entry. This modify request fails because the new value is already present.
The entry is left with a memberof value that points to the obsolete group DN.
The solution is for refint to set the manageDsaIt control on its repair ops,
and for memberof to ignore Modify requests with this control set.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10408
Issue ID: 10408
Summary: syncprov_op_search bailout: branch doesn't expect sop
removal happened already
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: ---
There are codepaths in syncprov_op_search that reach 'bailout:' when it's
possible for syncprov_op_abandon to have snuck in and remove the 'syncops *'
from the list in the meantime. However this branch always expects to find it
there. Fix is coming.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10376
Issue ID: 10376
Summary: 'this' seems to be duplicated in '8.4.5. Managing
access with Groups' section
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: truth_jp_4133(a)yahoo.co.jp
Target Milestone: ---
At the sentense 'One can then grant access to the members of this this group by
adding appropriate by group clause to an access directive in slapd.conf(5).' in
'8.4.5. Managing access with Groups' section, 'this' seems to be duplicated.
https://www.openldap.org/doc/admin26/access-control.html
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10348
Issue ID: 10348
Summary: Free ch_malloc-allocated memory in error paths
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
Created attachment 1077
--> https://bugs.openldap.org/attachment.cgi?id=1077&action=edit
Patch: Relase memory allocated from ch_malloc in 2 error handling branches.
In ldap_back_monitor_ops_init and syncrepl_dirsync_message, memory allocated
with ch_malloc was not freed when errors occurred. This adds two ch_free calls
to ensure proper cleanup in those branches.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10392
Issue ID: 10392
Summary: back-ldap does not return a response if incorrect
secprops is configured
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
If a non-existent secprops mechanism is configured as part of a back-ldap
idassert-bind directive, back-ldap does not return a response to the following
requests, leaving the client waiting. In the same case meta and asyncmeta would
return an LDAP error. My guess is failure to establish the target connection is
handled incorrectly in that code path.
--
You are receiving this mail because:
You are on the CC list for the issue.