openldap-bugs July 2021

openldap-bugs@openldap.org

1 participants
261 discussions

[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 9614] New: Admin guide does not document olcMultiVal
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=9614 Issue ID: 9614 Summary: Admin guide does not document olcMultiVal Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide is missing documentation on the new olcMultiVal attribute despite it being noted in the admin guide 2.5 upgrade section. Need to add a detailed section on it. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9613] New: olcIdlExp is not documented in the admin guide
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=9613 Issue ID: 9613 Summary: olcIdlExp is not documented in the admin guide Product: OpenLDAP Version: 2.5.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The admin guide does not document idlexp but does recommend configuring it before upgrading to 2.5. We need to add this to the admin guide with a detailed explanation of what it does. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[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

[Bug 9220] New: Rewrite Bind and Exop result handling
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

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.

1 6

[Issue 6138] Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=6138 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9220 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6138] Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=6138 --- Comment #9 from Howard Chu <hyc(a)openldap.org> --- (In reply to Hallvard Furuseth from comment #2) > back-ldap:extended.c also does "suppress response, it has been sent", > but does it by returning and setting rs->sr_err = SLAPD_ABANDON. Might > break assumptions somewhere that SLAPD_ABANDON implies o_abandon was > set. And I guess the hack fails if the operation gets cancelled. Now fixed to always let the frontend handle responses. But this is still awkward, and will need to be revisited again for ITS#9220. > ======================================================================== > > I think these are the Operation states related to Cancel and Abandon: > > op->o_abandon is set for these - could extend to multiple values: > A) Operation Abandoned/Cancelled by client. > B) Operation implicitly abandoned by client. (Bind or lost connection) > C) Operation abandoned by server. (It wants to close the connection) > D) Suppress response - a duplicate of the operation will proceed. (syncprov) > E) Suppress response - final send_ldap_response() was done. (retcode overlay) > > rs->sr_err == SLAPD_ABANDON if: > F) The backend obeyed o_abandon. (Cancel op, if any, will succeed) > G=E) Suppress response - final send_ldap_response() was done. (back-ldap) D, E, and G will no longer occur. > op->o_cancel packs these states/values: > H) The o_abandon is due to a Cancel. > I) Cancel operation wants a result, cancelled op must set it and wait. > J) Result is available to the Cancel operation. > K) Result. (LDAP result code, or SLAP_CANCEL_ACK for success) > L) Cancel operation has fetched result, cancelled operation can proceed. > > States that fit in none of the above, or poorly so: > > M) Operation must not be waited for, e.g. by Cancel. > Operation is itself waiting for others, e.g. cn=config update. > > N) Operation invisible to Abandon/Cancel/internal abandon. > msgID reusable due to result sent to client. Also case D (syncprov)? > > Fix by removing the op from op->o_conn->c_ops? Or does that just > move the problem around? Would need to do something to o_conn to > prevent connection_close() from doing connection_destroy(). > > O) Operation result has been committed, do not abandon. ITS#6059. > > But o_abandon can be set while trying to commit, unless this flag is > set before trying - in which case we can't abandon an operation which > is failing to commit, which may be when it's most relevant. > > Could reset o_abandon, if anyone can keep straight the consequences. > Or replace the 'if ( op->o_abandon )' tests with some macro call. > Still, interactions with other states could be a problem. > > About the o_abandon values above: > > B can be treated like A, I think. > C differs in that Cancel/Abandon(operation) should not say "already > abandoned" since the client doen't know about the abandon. > Could be solved with a vague error message. > > D-E differ in that o_abandon gets set even though the backends' > cancel/abandon handlers were not called. Unsure of the effects of that. > > D Syncprov duplicating a Persistent Search operation. > Handled similar to a server-initiated abandon? Except if the > operation cannot be "invisible to Abandon/Cancel" above it must remain > possible to Abandon/Cancel it. > > E Suppress response - response has been sent: > Set when exiting slap_send_ldap_result() & co? > > Handled similar to a server-initiated abandon? > At the time slap_send_ldap_result() is called again, the operation > may have set up things which need to be cleaned up in the normal way. > Yet it has already gone through that function once, doing callbacks > etc. Must "final response" code be prepared to be called twice? > > Beyond that, the main problem would be code which transitions to one > state to another, it needs to handle the other cases. > > -- > Hallvard -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8890] adapt to 64-bit time_t on systems with 32-bit long
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=8890 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Adapt timet to 64-bit long |adapt to 64-bit time_t on | |systems with 32-bit long -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6138] Bad Cancel/Abandon/"internal abandon"/Syncprov interactions
by openldap-its＠openldap.org 27 Jul '21

27 Jul '21

https://bugs.openldap.org/show_bug.cgi?id=6138 --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/365 -- 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
...
27
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2021