https://bugs.openldap.org/show_bug.cgi?id=9578
Issue ID: 9578
Summary: Buffer overflow at libraries/libldap/ldif.c:907
(ldif_read_record)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Created attachment 827
--> https://bugs.openldap.org/attachment.cgi?id=827&action=edit
fix
libraries/libldap/ldif.c:829
> /* Squash \r\n to \n */
> if ( len > 1 && line[len-2] == '\r' ) {
> len--;
> line[len-1] = '\n';
> }
may cause buffer overflow at
libraries/libldap/ldif.c:907
> strcpy( *bufp + lcur, line );
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9591
Issue ID: 9591
Summary: Solaris builds broken due to map file
Product: OpenLDAP
Version: 2.5.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Solaris 11.4 fails to build because it uses a different option for the library
symbol versioning map file. We need to detect this and provide the correct
option (more at
https://blogs.oracle.com/solaris/regex_and_glob_for_mapfiles-v2)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9220
Bug ID: 9220
Summary: Rewrite Bind and Exop result handling
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Bind and Exop result handling needs a rewrite so it is no longer a special case
for overlays.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9593
Issue ID: 9593
Summary: excessive null check in set_chase()
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Looks like slap_set_join( cp, nset, '|', vals ) can't return null, so return
value at line 411 should be treated like one at line 402:
servers/slapd/sets.c:399, set_chase():
for ( i = 0; !BER_BVISNULL( &set[ i ] ); i++ ) {
vals = gatherer( cp, &set[ i ], desc );
if ( vals != NULL ) {
/*402: */ nset = slap_set_join( cp, nset, '|', vals );
}
}
ber_bvarray_free_x( set, cp->set_op->o_tmpmemctx );
if ( closure ) {
for ( i = 0; !BER_BVISNULL( &nset[ i ] ); i++ ) {
vals = gatherer( cp, &nset[ i ], desc );
if ( vals != NULL ) {
/*411: */ nset = slap_set_join( cp, nset, '|', vals );
if ( nset == NULL ) {
break;
}
}
}
}
diff --git a/servers/slapd/sets.c b/servers/slapd/sets.c
index fc7b72c8b..17a6ec2c1 100644
--- a/servers/slapd/sets.c
+++ b/servers/slapd/sets.c
@@ -409,9 +409,6 @@ set_chase( SLAP_SET_GATHER gatherer,
vals = gatherer( cp, &nset[ i ], desc );
if ( vals != NULL ) {
nset = slap_set_join( cp, nset, '|', vals );
- if ( nset == NULL ) {
- break;
- }
If I'm wrong, return value at line 402 must be checked for null.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9211
Bug ID: 9211
Summary: Relax control is not consistently access-restricted
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
The following operations can be performed by anyone having 'write' access (not
even 'manage') using the Relax control:
- modifying/replacing structural objectClass
- adding/modifying OBSOLETE attributes
Some operations are correctly restricted:
- adding/modifying NO-USER-MODIFICATION attributes marked as manageable
(Modification of non-conformant objects doesn't appear to be implemented at
all.)
In the absence of ACLs for controls, I'm of the opinion that all use of the
Relax control should require manage access. The Relax draft clearly and
repeatedly discusses its use cases in terms of directory _administrators_
temporarily relaxing constraints in order to accomplish a specific task.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9431
Issue ID: 9431
Summary: back-mdb: Always have an equality index for
objectClass
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
Data storage backends require an equality index on objectClass to function
correctly. As this is a hard requirement it should be automatic with back-mdb.
Why this wasn't done in the past with other backends isn't exactly clear, it
may have been due to their requirements to have additional cache layers. That
however is not necessary with back-mdb.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/mta…
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9592
Issue ID: 9592
Summary: recursion operator (*) for acl “sets” does not work as
documented
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
I have traced how the slapd computes recursion operator (*) in acl's “sets” and
found out that it does not work as documented. IIUC, the reference
documentation is:
“Sets in Access Controls”
(http://www.openldap.org/faq/index.cgi?file=1133)
To make things simpler, I report the finding using the example provided by the
documentation. Here it is:
entry "cn=Group" has attr "member" with values { "cn=User", "cn=Other" }
entry "cn=Group2" has attr "member" with values { "cn=Group", "cn=Person" }
The documentation claims that the expression
“[cn=Group2]/member*” resolves to { "cn=User", "cn=Other", "cn=Person" }
In fact, it resolves to { "cn=Group", "cn=User", "cn=Other", "cn=Person" }.
To generalize: all intermediate dn's persist in a set, that's how set_chase(
closure = 1 ) works, and this doesn't look like that's how it's supposed to
work.
Be advised, please, that this issue has been reported by occasional visitor,
from a developer point of view, not a user point of view, so I won't define,
provide or construct any “valid use case”.
--
You are receiving this mail because:
You are on the CC list for the issue.