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=10370
Issue ID: 10370
Summary: result.c:930: try_read1msg: Assertion `!BER_BVISEMPTY(
&resoid )' failed.
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: daniel(a)haxx.se
Target Milestone: ---
When using curl built with OpenLDAP to access a broken/malicious ldap server,
OpenLDAP will abort on this assert.
It seems it should rather return a proper error code?
A full reproducer that unfortunately uses curl is available here:
https://hackerone.com/reports/3258022 together with more details about this
problem.
(I'm forwarding this information, I did not discover this.)
--
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.
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=10359
Issue ID: 10359
Summary: delta-MPR uses logbase for more than it documents
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: ---
syncrepl logbase=<dn> is used not just for a syncrepl session (documented) but
also for internal searches when it comes to delta-MPR conflict resolution. This
is not documented so an admin doesn't know that the local accesslog DB needs to
exist and have the same suffix.
Either the documentation needs updating or a new configuration item needs to be
added to allow an accesslog DB with a different suffix locally.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10347
Issue ID: 10347
Summary: Fix a memory leak in function comp_convert_asn_to_ldap
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: ---
Created attachment 1076
--> https://bugs.openldap.org/attachment.cgi?id=1076&action=edit
Patch: Fix a memory leak in function comp_convert_asn_to_ldap
In function comp_convert_asn_to_ldap, the bv->bv_val is allocated in 3 places:
case BASICTYPE_BOOLEAN: bv->bv_val = (char*)malloc( 5 );
case BASICTYPE_INTEGER: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE );
case BASICTYPE_ENUMERATED: bv->bv_val = (char*)malloc( INITIAL_ATTR_SIZE );
When csi->csi_syntax != NULL and csi->csi_syntax->ssyn_pretty != NULL,
bv->bv_val is overwriten with bv->bv_val = prettied.bv_val;, causing porential
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=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=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=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=10343
Issue ID: 10343
Summary: Potential Memory Leak in function
slap_uuidstr_from_normalized
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 1070
--> https://bugs.openldap.org/attachment.cgi?id=1070&action=edit
Patch: Change 1 to -1.
In function slap_uuidstr_from_normalized, the code allocates a new `struct
berval` with
```c
new = (struct berval *)slap_sl_malloc(sizeof(struct berval), ctx);
```
and then attempt to allocate `new->bv_val`. If that second allocation fails, it
sets `rc = 1` and jumps to the `done` cleanup label. However, the cleanup code
only runs when `rc == -1`, so the memory pointed by `new` is never freed,
causing a memory leak.
--
You are receiving this mail because:
You are on the CC list for the issue.