https://bugs.openldap.org/show_bug.cgi?id=10375
Issue ID: 10375
Summary: [patch] minor patch to const up oids array
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: caolanm(a)gmail.com
Target Milestone: ---
Created attachment 1084
--> https://bugs.openldap.org/attachment.cgi?id=1084&action=edit
minor patch to const up oids array
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10335
Issue ID: 10335
Summary: [PATCH] ldapsearch: fix handling of -LL in
print_reference()
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: bolek(a)live.com
Target Milestone: ---
Created attachment 1066
--> https://bugs.openldap.org/attachment.cgi?id=1066&action=edit
[PATCH] ldapsearch: fix handling of -LL in print_reference()
I, Boleslaw Ciesielski, hereby place the following modifications to OpenLDAP
Software (and only these modifications) into the public domain. Hence, these
modifications may be freely used and/or redistributed for any purpose with or
without attribution and/or other notice.
The attached patch (against master) fixes a bug in ldapsearch where the -LL (or
-LLL) option is ignored when printing the reference comments in
print_reference().
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10372
Issue ID: 10372
Summary: support lastbind_forward_updates outside of the
lastbind overlay
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: lklement(a)symas.com
Target Milestone: ---
according to the documentation for the LastBind overlay (slapo-lastbind) this
overlay is no longer recommended unless lastbind_forward_updates is used.
Can this functionality be added to the current lastbind configuration
recommendation?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10366
Issue ID: 10366
Summary: Is 'second database definition & config directives'
block duplicated?
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: ---
I have a question about an example of '6.1. Configuration File Format' section
on this page (https://www.openldap.org/doc/admin26/slapdconfig.html).
I think that 'second database definition & config directives' section is
duplicated.
Is the second 'second database definition & config directives' to be 'third
database definition & config directives'?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10345
Issue ID: 10345
Summary: Potential memory leak in function rbac_create_session
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: alexguo1023(a)gmail.com
Target Milestone: ---
In `rbac_create_session`, we have the following code:
```c
if ( rc < 0 ) {
rs->sr_err = LDAP_OTHER;
rs->sr_text = "internal error";
} else {
(void)ber_flatten( ber, &rs->sr_rspdata );
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); // first
rs->sr_err = LDAP_SUCCESS;
}
ber_free_buf(ber);
done:;
// always put the OID in the response:
rs->sr_rspoid = ch_strdup( slap_EXOP_CREATE_SESSION.bv_val ); //second
```
The second `ch_strdup` at the `done` label overwrites `rs->sr_rspoid` without
freeing the previous string, resulting in a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10377
Issue ID: 10377
Summary: The words (addressbooks/addressbook) seems to be
mismatched in the DIT example and the ACL example.
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: ---
In '8.4.8. Allowing entry creation' section, the DIT example is
'ou=addressbooks'.
On the other hand, the ACL example is 'ou=addressbook,'.
So the words (addressbooks/addressbook) seems to be mismatched in the DIT
example and the ACL example.
--
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=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=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.