openldap-bugs

openldap-bugs@openldap.org

1 participants
21001 discussions

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Hi, Le Mer 2 mars 2011 17:51, masarati(a)aero.polimi.it a écrit : > >> The following patch > > Please upload patches according to > <http://www.openldap.org/devel/contributing.html#submitting>. As said in the post, no success: $ ftp ftp> open ftp.openldap.org Connected to www.openldap.org. 220- OpenLDAP FTP Service 220 boole.openldap.org FTP server (Version 6.00LS) ready. Name (ftp.openldap.org:raphael): ftp 331 Guest login ok, send your email address as password. Password: 230- Copyright 1998-2010, The OpenLDAP Foundation, All Rights Reserved. 230- COPYING RESTRICTIONS APPLY, see: 230- ftp://ftp.openldap.org/COPYRIGHT 230- ftp://ftp.openldap.org/LICENSE 230 Guest login ok, access restrictions apply. Remote system type is UNIX. Using binary mode to transfer files. ftp> ascii 200 Type set to A. ftp> cd incoming 250 CWD command successful. ftp> put raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch local: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch remote: raphael-ouazana-110302-sssvlv-fix-free_sort_op-segfault.patch 200 PORT command successful. 425 Can't build data connection: Connection refused. ftp> Regards, Raphael Ouazana.

1 0

Re: (ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> The following patch Please upload patches according to <http://www.openldap.org/devel/contributing.html#submitting>. p.

1 0

(ITS#6850) sssvlv can segfault when releasing multiple requests by conn
by raphael.ouazana＠linagora.com 02 Mar '11

02 Mar '11

Full_Name: Raphael Ouazana Version: HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) Hi, sssvlv support for multiple requests by conn (see ITS#6686) can segfault while releasing some connections. Indeed, the request to release can be searched by the ps_cookie. But as the ps_cookie is NULL at the end of the request (it points to so_tree), the same request can be freed multiple times. The following patch fix this issue and reinforce the rest of the code by using so to search for the matching request where it is possible. Sorry, no FTP upload, I get an error 425. It fixes a little error in the man page too. Index: doc/man/man5/slapo-sssvlv.5 =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/doc/man/man5/slapo-sssvlv.5,v retrieving revision 1.4 diff -u -r1.4 slapo-sssvlv.5 --- doc/man/man5/slapo-sssvlv.5 4 Jan 2011 23:42:55 -0000 1.4 +++ doc/man/man5/slapo-sssvlv.5 2 Mar 2011 16:40:57 -0000 @@ -17,8 +17,8 @@ Since a complete result set must be generated in memory before sorting can be performed, processing sort requests can have a large impact on the server's memory use. As such, any connection is limited to having only -one sort request active at a time. Additional limits may be configured -as described below. +a limited number of sorts requests active at a time. Additional limits may +be configured as described below. .SH CONFIGURATION These Index: servers/slapd/overlays/sssvlv.c =================================================================== RCS file: /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays/sssvlv.c,v retrieving revision 1.29 diff -u -r1.29 sssvlv.c --- servers/slapd/overlays/sssvlv.c 4 Jan 2011 23:43:32 -0000 1.29 +++ servers/slapd/overlays/sssvlv.c 2 Mar 2011 16:40:58 -0000 @@ -342,6 +342,23 @@ } /* Return the session id or -1 if unknown */ +static int find_session_by_so( + int svi_max_percon, + int conn_id, + sort_op *so ) +{ + int sess_id; + if (so == NULL) { + return -1; + } + for (sess_id = 0; sess_id < svi_max_percon; sess_id++) { + if ( sort_conns[conn_id] && sort_conns[conn_id][sess_id] == so ) + return sess_id; + } + return -1; +} + +/* Return the session id or -1 if unknown */ static int find_session_by_context( int svi_max_percon, int conn_id, @@ -379,14 +396,13 @@ static void free_sort_op( Connection *conn, sort_op *so ) { int sess_id; - PagedResultsCookie ps_cookie = (PagedResultsCookie) so->so_tree; if ( so->so_tree ) { tavl_free( so->so_tree, ch_free ); so->so_tree = NULL; } ldap_pvt_thread_mutex_lock( &sort_conns_mutex ); - sess_id = find_session_by_context( so->so_info->svi_max_percon, conn->c_conn_idx, so->so_vcontext, ps_cookie ); + sess_id = find_session_by_so( so->so_info->svi_max_percon, conn->c_conn_idx, so ); sort_conns[conn->c_conn_idx][sess_id] = NULL; so->so_info->svi_num--; ldap_pvt_thread_mutex_unlock( &sort_conns_mutex ); @@ -492,7 +508,7 @@ sc->sc_nkeys * sizeof(struct berval), op->o_tmpmemctx ); sn->sn_vals = (struct berval *)(sn+1); sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, vc->vc_context, NO_PS_COOKIE ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); sn->sn_vals[0] = bv; for (i=1; i<sc->sc_nkeys; i++) { BER_BVZERO( &sn->sn_vals[i] ); @@ -731,7 +747,7 @@ op->o_tmpfree( sn, op->o_tmpmemctx ); sn = sn2; sn->sn_conn = op->o_conn->c_conn_idx; - sn->sn_session = find_session_by_context( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so->so_vcontext, (PagedResultsCookie) so->so_tree ); + sn->sn_session = find_session_by_so( so->so_info->svi_max_percon, op->o_conn->c_conn_idx, so ); /* Insert into the AVL tree */ tavl_insert(&(so->so_tree), sn, node_insert, avl_dup_error); Legal notice: This patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in this following patch were developed by Raphael Ouazana raphael.ouazana(a)linagora.com. These modifications are not subject to any license of Linagora. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2011 Raphael Ouazana, Linagora Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

Lib is not relocatable although --with-pic was used. Bug?
by Kristof Van Damme 02 Mar '11

02 Mar '11

Hi all, Platform is Sun Solaris x64 10 u8. Compiler used is Sun Studio 12u1. Version is openldap-2.4.23-stable-20100719. Configure was done with CFLAGS='-xO3 -KPIC -m64 -xtarget=generic' and CC="/usr/bin/cc" $ ./configure --prefix=/opt/app/damp64 --with-pic --with-tls=openssl Compilation in 64-bit (-m64) of libldap was succesfull and installed in /opt/app/damp64/lib. If I create a simple main.c file: int main(){ return 0; } I compile (also 64-bit) and link this main.c file with libldap as a test. $ /usr/bin/cc -o conftest -xO4 -m64 -KPIC -xtarget=generic -s -I/opt/app/damp64/include -L/opt/app/damp64/lib -R/opt/app/damp64/lib main.c -lldap When I try to run this exec linked to the newly build library libldap.so I get the following error: # ./conftest ld.so.1: conftest: fatal: relocation error: R_AMD64_32: file /opt/app/damp64/lib/libldap-2.4.so.2: symbol (unknown): value 0xfffffd7fff2542f0 does not fit This is a relocation error from the linker on the libldap. But I compiled everything with -KPIC (position independent code) and gave the --with-pic option to configure. This is a serious issue, as I cannot link the library to anything else and thus it is unusable. Can I file a bug report? If I have a look in the libldap shared object, I can see .text relocations... # elfdump -d /opt/app/damp64/lib/libldap-2.4.so.2 | fgrep TEXTREL [18] TEXTREL 0 [27] FLAGS 0x4 [ TEXTREL ] Kind regards, Kristof Van Damme.

1 1

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> Full_Name: plop > Version: > OS: ubuntu last release > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.206.236.129) > > > This is what I got on a CLI: > > ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b > "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin > ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: > tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' > failed. > Abandon > > > > $ ldapsearch -V > ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ > buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools > (LDAP library: OpenLDAP 20423) > ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) Fixed in HEAD. Tools will refuse to start if incompatible password options are passed. I chose this solution since handling of credentials is security-related, and one would not want credentials to be handled incorrectly by a misused client. Please test. p.

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. I understand the fix I'm suggesting can sound counter-intuitive. The documentation should clearly indicate that the binddn in case of SASL is for *local* and *internal* issues, and will not be part of the authentication process. As an alternative, lc_bound_ndn could receive a dummy DN (e.g. "cn=auth") to merely indicate a successful bind (or receive the actual identity from the remote server using the authid control along with the bind or performing a whoami extop later, as already implemented). p. > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. > >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >

1 0

Re: (ITS#6817) idassert-bind with SASL issues
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

> masarati(a)aero.polimi.it wrote: >> Full_Name: Pierangelo Masarati >> Version: HEAD/re24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (2.40.14.92) >> Submitted by: ando >> >> >> When idassert-bind is configured to use SASL bind, an "authcID" needs to >> be >> provided, while the "binddn" is not needed. However, if a "binddn" is >> not >> provided as well, in some cases the proxiedAuthz control may be used >> incorrectly. The need to configure the "binddn" is not documented, so >> this ITS >> is minimally addressed by documenting this requirement. > > I tripped over this change while investigating #6711. Adding this > requirement > is certainly not the right solution; SASL Binds ordinarily don't require a > BindDN and requiring it here just makes things confusing. > > Also with the fixes that I made for #6711 I don't believe the issue exists > any > more. Please describe the conditions where the problem occurs. At the time I looked at this issue, there were places in the code where after an idassert-bind the lc_bound_ndn would receive a copy of idassert's authcDN. In case of SASL, this is empty/null; then back-ldap (and meta) would fail from recognizing the connection as successfully bound. I understand there are better solutions; for example, ldapconn_t could have a "bound" flag, or so. I understand that code may need some reworking, but I can't work at that now, sorry. p. >> If the "binddn" is provided, everything works as expected, with the only >> minor >> issue that the DN of the user as it is known to back-meta may not match >> the >> actual identity the "authcID" assumed on the remote server. The "right" >> way to >> address this problem consists in performing a "WhoAmI" (RFC 4532) right >> after >> the bind, or better use a "authorization identity control" (RFC 3829) >> along with >> the bind operation. Both approaches should be implemented, but they >> should not >> be used unless explicitly requested. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > >

1 0

Re: (ITS#6849) ldapsearch assertion failed
by masarati＠aero.polimi.it 02 Mar '11

02 Mar '11

1 0

Re: (ITS#6839) Expanded documentation for ldapi: and SASL EXTERNAL
by ghenry＠OpenLDAP.org 01 Mar '11

01 Mar '11

----- Original Message ----- > --GRPZ8SYKNexpdSJ7 > Content-Type: text/plain; charset=us-ascii > Content-Disposition: inline > > On Fri, Feb 18, 2011 at 02:56:16PM -0800, Howard Chu wrote: > > > re: TLS Authentication Identity Format > > > > Strictly speaking, the order of components is not changed at all. > > The sequence of RDNs in the DN is what it is; just that the > > convention for *displaying* it is ass-backwards in LDAP. I'm afraid > > the wording here will confuse people into thinking that the > > *semantics* of the DN are changed, when it's only a display issue. > > Good point. Updated wording attached. > > Andrew Thanks for all this Andrew, much appreciated! -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

1 0

(ITS#6849) ldapsearch assertion failed
by gnuround＠gmail.com 01 Mar '11

01 Mar '11

Full_Name: plop Version: OS: ubuntu last release URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.206.236.129) This is what I got on a CLI: ldapsearch -x -H ldap://10.1.9.100 -D "cn=admin,o=calculus" -LLL -W -b "ou=Users,ou=toto,ou=Customers,o=calculus" -w passadmin ldapsearch: /build/buildd/openldap-2.4.23/clients/tools/common.c:1363: tool_bind: Assertion `passwd.bv_val == ((void *)0) && passwd.bv_len == 0' failed. Abandon $ ldapsearch -V ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.23 (Nov 19 2010 17:41:00) $ buildd@allspice:/build/buildd/openldap-2.4.23/debian/build/clients/tools (LDAP library: OpenLDAP 20423) ldap_sasl_interactive_bind_s: Can't contact LDAP server (-1) $ apt-cache show ldap-utils Package: ldap-utils Priority: optional Section: net Installed-Size: 768 Maintainer: Ubuntu Developers <ubuntu-devel-discuss(a)lists.ubuntu.com> Original-Maintainer: Debian OpenLDAP Maintainers <pkg-openldap-devel(a)lists.alioth.debian.org> Architecture: amd64 Source: openldap Version: 2.4.23-0ubuntu3 Replaces: openldap-utils, openldapd, slapd (<< 2.2.23-0.pre6) Provides: ldap-client, openldap-utils Depends: libc6 (>= 2.4), libgnutls26 (>= 2.7.14-0), libgssapi-krb5-2 (>= 1.6.dfsg.2), libldap-2.4-2 (= 2.4.23-0ubuntu3), libsasl2-2 Recommends: libsasl2-modules Conflicts: ldap-client, openldap-utils, umich-ldap-utils Filename: pool/main/o/openldap/ldap-utils_2.4.23-0ubuntu3_amd64.deb Size: 343860 MD5sum: 5c7834714c933288181d660e34c0b3d6 SHA1: a18afe09abd61bcf6a722135bb82c308104fa15c SHA256: 1b2d43b4dc82843047d6930f8e1f4145a8cf40f9435d9d58389c7acd1a4d4b04 Description-fr: Utilitaires OpenLDAP

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs