openldap-bugs June 2021

openldap-bugs@openldap.org

1 participants
303 discussions

[Issue 9601] New: Remove the build warnings in tpool.c
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=9601 Issue ID: 9601 Summary: Remove the build warnings in tpool.c Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: Bin.Lan(a)windriver.com Target Milestone: --- Created attachment 828 --> https://bugs.openldap.org/attachment.cgi?id=828&action=edit the issue patch tpool.c:721:12: warning: 8 enumeration values not handled in switch: 'LDAP_PVT_THREAD_POOL_PARAM_UNKNOWN', 'LDAP_PVT_THREAD_POOL_PARAM_MAX', 'LDAP_PVT_THREAD_POOL_PARAM_MAX_PENDING'... [-Wswitch] switch(param) { ^ 1 warning generated. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9590] New: missed mutex unlock
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=9590 Issue ID: 9590 Summary: missed mutex unlock 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: --- Unlikely causes a harm, but oughts fixing ... diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index 7fe9f9c29..05f6a84c8 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -349,8 +349,9 @@ ldap_init_fd( LDAP_MUTEX_LOCK( &ld->ld_conn_mutex ); /* Attach the passed socket as the LDAP's connection */ conn = ldap_new_connection( ld, NULL, 1, 0, NULL, 0, 0 ); if( conn == NULL ) { + LDAP_MUTEX_UNLOCK( &ld->ld_conn_mutex ); ldap_unbind_ext( ld, NULL, NULL ); return( LDAP_NO_MEMORY ); } if( url ) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9578] New: Buffer overflow at libraries/libldap/ldif.c:907 (ldif_read_record)
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

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.

1 3

[Issue 9591] New: Solaris builds broken due to map file
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

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.

1 6

[Issue 9593] New: excessive null check in set_chase()
by openldap-its＠openldap.org 26 Jul '21

26 Jul '21

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.

1 3

[Issue 9592] New: recursion operator (*) for acl “sets” does not work as documented
by openldap-its＠openldap.org 06 Jul '21

06 Jul '21

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.

1 3

[Issue 9595] New: indeterminate result of matching AVA in filter
by openldap-its＠openldap.org 27 Jun '21

27 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9595 Issue ID: 9595 Summary: indeterminate result of matching AVA in filter 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 test_ava_filter() matches an entry against an AVA and found out that result of matching may be indeterminate. For concreteness, let us suppose an entry E is being matched against equality ava (A1=U). E has a few values for A1, in this particular order: Attr Value (A1=U) match ---- ----- ------------ A1 V False A1 U True A1 @$%#^ #LDAP_INVALID_SYNTAX overall matching result: TRUE. But what if A1 values follow in other order? Attr Value (A1=U) match ---- ----- ------------ A1 V False A1 @$%#^ #LDAP_INVALID_SYNTAX A1 U True overall matching result: #LDAP_INVALID_SYNTAX. But... wait, E has one more attribute A2, which subclasses A1. And their values happen to be in this order: Attr Value (A1=U) match ---- ----- ------------ A1 V False A1 @$%#^ #LDAP_INVALID_SYNTAX A1 U True A2 U True A2 *%#$! #LDAP_INVALID_SYNTAX overall matching result: TRUE again. It seems rather unnatural and confusing that the given set of attributes and their values has indeterminate result of matching. 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.

1 2

[Issue 9594] New: The characters not allowed in SASL ids used with olcAuthzRegexp are undocumented
by openldap-its＠openldap.org 27 Jun '21

27 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9594 Issue ID: 9594 Summary: The characters not allowed in SASL ids used with olcAuthzRegexp are undocumented Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Some characters cannot be used in SASL ids processed by the SASL mechanism that olcAuthzRegexp configures. It is undocumented which characters are allowed and which are not. See also ITS bug number 9495. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9495] New: authz-regexp using dn: instead of a URI mangles characters with HTML excapes
by openldap-its＠openldap.org 25 Jun '21

25 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9495 Issue ID: 9495 Summary: authz-regexp using dn: instead of a URI mangles characters with HTML excapes Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Trying to use an authz-regexp that maps directly to dn-s by using "dn:..." instead of a URI results in the authz id having some characters "html escaped". As a result the authorized entity cannot be found. E.g. a "-U cn=Barbara Jensen,ou=Information Technology Division" with olcAuthzRegexp: "^uid=([^,]+),.*" "dn:$1,ou=people,dc=example,dc=com" fails. Debug logs show that the equal and the comma character return from ldap_bv2dn() in escaped forms, that are then substituted into the target dn and result in a dn that does not exist in the DIT. 6046d7cd SASL Canonicalize [conn=1113]: authcid="cn=Barbara Jensen,ou=Informatio n Technology Division" 6046d7cd slap_sasl_getdn: conn 1113 id=cn=Barbara Jensen,ou=Information Technolo gy Division [len=52] => ldap_dn2bv(16) <= ldap_dn2bv(uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth)=0 6046d7cd slap_sasl_getdn: u:id converted to uid=cn\3DBarbara Jensen\2Cou\3DInformation Technology Division,cn=PLAIN,cn=auth ... 6046d7cd send_ldap_result: err=49 matched="" text="SASL(-13): user not found: Password verification failed" I suspect that when the "dn:..." form is used with authz-regexp the supplied authzid should _not_ have it's characters canonicalized because they will not be substituted into a URI. If so, this would be a bug. If not, there should be documentation on the restrictions on what characters can be used in authzid when the "dn:..." form is used. Tested against HEAD of master, although the version in the bug report is 2.5. See also Bug# 6912. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 8788] slapd-pcache undef not compatible with mdb
by openldap-its＠openldap.org 24 Jun '21

24 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=8788 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • f6dcc600 by Quanah Gibson-Mount at 2021-06-24T17:48:21+00:00 ITS#8788 - Document that "undef" is not usable with back-mdb -- You are receiving this mail because: You are on the CC list for the issue.

1 0

← Newer
1
...
7
8
9
10
11
12
13
...
31
Older →

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs June 2021